[systemd-devel] yum-updateonboot with Systemd

[Lennart Poettering]

On Thu, 21.07.11 11:28, Matthew Miller (mattdm at mattdm.org) wrote:

> 
> On Wed, Jul 20, 2011 at 08:46:00PM +0200, Lennart Poettering wrote:
> > However, I don't think something like you suggest is feasible. In a
> > modern environment network connectivity is dynamic: it comes and goes
> > and comes and goes, and its's properties change. A robust system should
> 
> That's definitely one design pattern for modern environments, particularly
> home users and for smaller, more flexible workplaces. It's not necessarily
> the case for larger-scale use. One particular case is computer labs (which
> still exist -- we just got go-ahead for a rather expensive one). There, the
> network connectivity is pretty much a given and if the network properties
> change it's either a big problem or else something we've planned in
> advance.

I wouldn't really distuingish this too much. Even in computer labs you
step on cables from time to time, or you don't use static IP addresses
anymore and your DHCP server is down, or something else happens. I think
it is wise to make the best out of every situation and react as well as
possible to any of these situations, and recover from failure. Just
freezing boot otoh is bad idea I'd say though, regardless how "movable"
your machine is.

> Maybe the right answer is to have an "apply system updates" target, which
> starts only what's needed for the update system, and then move from that to
> the multiuser target, rather than trying to shoehorn it in to the general
> startup. 
> 
> In fact, to be safe, I can imagine a startup procedure where
> sysupdates.target is the boot default, and when that completes it switches
> to multiuser.target (via isolate, or even via kexec if a new kernel is
> required).

So, what I'd suggest instead is this, keeping in mind that you seldom
reboot your machines:

When you want to do a software upgrade, run a tiny service on the
machine in question, which (after verifying that nobody is logged in)
uses "systemctl snapshot pre-upgrade.snapshot" to generate snapshot unit
of the current system state. Then, it issues "systemctl isolate
upgrade.target", to enter the upgrade mode (of course, this tiny service
needs to be a dep of upgrade.target in order to ensure the script itself
isn't killed by that). This will then shutdown almost all services,
except a few ones you exclude. Then, do your upgrades, and finish off
with "systemctl isolate pre-upgrade.snapshot" and "systemctl delete
pre-upgrade.snapshot", which will start all services that were started
before.

You can do that at any time without rebooting, and your environment will
be as clean as it would be during boot. 

Lennart

-- 
Lennart Poettering - Red Hat, Inc.