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 -- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
