On Sun, 26.07.15 00:08, Andrei Borzenkov (arvidj...@gmail.com) wrote: > В Sat, 25 Jul 2015 12:50:39 +0200 > Michael Biebl <mbi...@gmail.com> пишет: > > > 2015-07-25 3:18 GMT+02:00 Rich Freeman <r-syst...@thefreemanclan.net>: > > > I noticed that mount units for nfs shares created by the generator do > > > not Want=nfs-client.target or similar. > > > > > > That means that if you don't explicitly want nfs-client in your > > > configuration then nfs shares will get mounted, but services like > > > rpc-statd-notify.service won't run. > > > > > > Would it make sense to have the generator add the nfs-client target as > > > a want to nfs mount services it creates? > > > > remote mount units do have a "After remote-fs-pre.target" ordering and > > tools like nfs-common/rpcbind are supposed to hook up into > > remote-fs-pre.target. > > > > They are supposed to be /ordered before/ remote-fs-pre.target; but I do > not remember that remote-fs-pre.target itself was intended to pull > anything. This was designed as pure synchronization point. > > > http://www.freedesktop.org/software/systemd/man/systemd.special.html#remote-fs-pre.target > > > > --><-- > Note that this unit is generally not part of the initial transaction, > unless the unit that wants to be ordered before all remote mounts pulls > it in via a Wants= type dependency. > --><-- > > So if I read it, nfs-common should pull in remote-fs-pre, but that > leaves question what should pull in nfs-common itself.
Remote mounts are ordered after network.target, after remote-fs-pre.target and after network-online.target. remote-fs-pre.target and network.target are indeed "passive", they should be pulled in by the service that wants to be the hook, not by the mount that uses it. r-f-p.t is specifically for network mounts in this case, while n.t is more generic. r-f-p.t is much stricter defined, while n.t is very loosely defined and mostly about shutdown order, not so much abotu startup order. n-o.t otoh is an "active" target, it's actively pulled in by all remote mounts, and hence can be used to add a service to the transaction as soon as a remote mount is attempted. Coming back to your original question, there are two options: 1) nfs-common becomes a normal multi-user.target service, but adds Before=remote-fs-pre.target. This way, the service is started at boot, and not only on first use. 2) nfs-common makes itself pulled in by network-online.target, and orders itself before that. This way, the service is started when the network is upped. If you are looking for a way to start this service only when an NFS mount is attempted, then I must disappoint you: there's currently no way to do this nicely, as you can neither express "applies only to NFS", nor is there a way to actively pull in things from remote mounts. (There's a reason for both limitations: we try to avoid pull-deps on mounts, since we want to keep the effect of manually ordered /bin/mount invocations, and systemd-ordered .mount activations as close as possible.) Hope this is useful, Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
