On Thu, 21.07.11 11:28, Matthew Miller ([email protected]) 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. _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
