On 20.07.2011 20:46, Lennart Poettering wrote: > On Wed, 20.07.11 14:11, Matthew Miller ([email protected]) wrote: > >> In general, it's useful to have an on-boot update service make sure any >> updates are applied before any daemons which might be updated are >> started. > > If so it is possible to stick it between early boot and late > boot. Use "After=sysinit.target mount.target" and "Before=basic.target" > and "DefaultDependencies=no" for that. > >> That is: >> >> On boot, a network-based update service runs as soon as the network is >> available, but before any of the services which might receive updates are >> started. >> >> User login services are one case, but in general "any service which might be >> accessible to someone" should count. (If the service starts earlier but can >> be restarted with the updated version before it is actually accessible, that >> is fine.) >> >> Is this possible with systemd? > > Well, systemd has an elaborate vocabulary which you use to express > ordering requirements. > > 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 > hence not require a network to be around for booting: it should boot up > just fine, and make use of the network as soon as it is available and > stop using it if it isn't anymore. Many daemons work like this since > quite some time, like Avahi or bind which listen to netlink changes. > > 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. > > 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. > > Lennart >
my suggestion is this: - download the updates in the background while network is available - upgrade the system on next reboot in an early phase _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
