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

Attachment: signature.asc
Description: Digital signature

Reply via email to