[systemd-devel] yum-updateonboot with Systemd

[Matthew Miller]

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.

And that's basically the same situation for servers.

> This goal is pretty much conflicting with what what you are asking for
> however: you want to unconditionally delay the boot until the network is
> up and we communicated with some service. 

Yes, that's definitely the case.

It would be nice if systemd were flexible enough to serve both goals. 

> So, yes, you can do that, by adding some complex ordering deps to your
> service, but in general i can only recommend avoiding this, to keep
> things fast, and robust and dynamic.

In this environment, booting happens infrequently, and deterministic
behavior is more important than rapid -- or even elegant -- startup. In
other words, of the three things you list there, only robust is important in
this context, and dynamic is looked at askance.


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).


-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>