On Sun, Dec 29, 2013 at 10:05:17PM +0100, Tollef Fog Heen wrote: > > It would, however, be nice if this were more clearly stated, since the > > guidance to the author of the unit file about what dependencies one should > > or should not explicitly add is a bit sparse. In particular, I wonder if > > there is an implicit After= dependency in a service unit on a socket unit > > of the same name (which would make sense given how Sockets= works), or if > > that's something that one should explicitly add.
> http://www.freedesktop.org/software/systemd/man/bootup.html has some > graphs. In addition, as long as your service is not doing anything in > the early boot, DefaultDependencies will be true and you'll have an > After=basic.target in your service. On Sun, Dec 29, 2013 at 01:18:00PM -0800, Russ Allbery wrote: > Tollef Fog Heen <tfh...@err.no> writes: > > ]] Russ Allbery > >> It would, however, be nice if this were more clearly stated, since the > >> guidance to the author of the unit file about what dependencies one should > >> or should not explicitly add is a bit sparse. In particular, I wonder if > >> there is an implicit After= dependency in a service unit on a socket unit > >> of the same name (which would make sense given how Sockets= works), or if > >> that's something that one should explicitly add. > > http://www.freedesktop.org/software/systemd/man/bootup.html has some > > graphs. In addition, as long as your service is not doing anything in > > the early boot, DefaultDependencies will be true and you'll have an > > After=basic.target in your service. > This by itself doesn't fully replace the implicit dependency. It ensures > ordering is correct for boot, but not that ordering is correct when > starting deactivated services, where the service startup is not happening > in the context of target processing. (Unless target processing happens in > more places than I think it does.) > It sounds, from Uoti's investigations, that the code also directly adds an > implicit dependency, which would ensure correct behavior in those cases as > well. Right. So between these two aspects of systemd's implied dependencies (which I believe postdate my previous investigations, given the behavior I observed at the time), it sounds like there are no races here for the general case, and I agree that this provides a solid mechanism for activation of services whose authors wish to avoid handling sockets directly. I'm also interested to know how systemd purports to handle the exceptional cases, where a dependency on basic.target is not possible. For instance, NFS mounts at boot: modern NFS on Linux requires a complex set of interdependent RPC daemons to be started on the client before an NFS share can be mounted. In my experience, these are some of the most complex boot-time interdependencies around, which would most benefit from something like socket-based activation to implicitly resolve ordering constraints. The nfs-common and rpcbind packages currently have no integration with systemd, so they get the default behavior for SysV services in rcS.d: WantedBy=sysinit.target, Before=sysinit.target. But there's nothing which documents that sysinit.target is a precondition for remote-fs.target, so in its current state, mounting of remote filesystems at boot is almost certainly racy with systemd in Debian. What does a correct implementation of NFS support on systemd look like? I've tried installing nfs-utils on Fedora 20, and while it provides a full set of native systemd units, surprisingly, the only one that references remote-fs-pre.target is nfs-lock. So it looks to me like this is another case where no one has actually done the work yet to properly integrate with systemd, and a migration to systemd would cause regressions for users of this configuration (and probably others). What is the right way to make nfs-common behave correctly on startup with systemd? Is there a reason that sockets.target is only a dependency of basic.target, not of remote-fs-pre.target, which would enable use of socket-based activation for fs helper daemons like those in nfs-common? (Note, of course, that nfs-utils currently has no support for the systemd socket activation protocol. However, if one of the arguments for systemd is socket activation, then I think we should explore the limits of how we think it should be used.) Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
