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 [email protected] <http://mattdm.org/> _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
