Hello On 01/12/2015 05:34 AM, Colin Guthrie wrote: > Hi, > > Looking into a thoroughly broken nfs-utils package here I noticed a > quirk in systemctl status and in umount behaviour. > > > In latest nfs-utils there is a helper binary shipped upstream called > /usr/sbin/start-statd (I'll send a separate mail talking about this > infrastructure with subject: "Running system services required for > certain filesystems") > > It sets the PATH to "/sbin:/usr/sbin" then tries to run systemctl > (something that is already broken here as systemctl is in bin, not sbin) > to start "statd.service" (again this seems to be broken as the unit > appears to be called nfs-statd.service upstream... go figure). The PATH problem has been fixed in the latest nfs-utils.
> > Either way we call the service nfs-lock.service here (for legacy reasons). With the latest nfs-utils rpc-statd.service is now called from start-statd But yes, I did symbolically nfs-lock.service to rpc-statd.service when I moved to the upstream systemd scripts. > > If this command fails (which it does for us for two reasons) it runs > "rpc.statd --no-notify" directly. This binary then run in the context of > the .mount unit and thus in the .mount cgroup. What are the two reason rpc.statd --no-notify fails? > > That seems to work OK (from a practical perspective things worked OK and > I got my mount) but are obviously sub optimal, especially when the mount > point is unmounted. > > In my case, I called umount but the rpc.statd process was still running: What is the expectation? When the umount should bring down rpc.statd? > > [root@jimmy nfs-utils]$ pscg | grep 3256 > 3256 rpcuser > 4:devices:/system.slice/mnt-media-scratch.mount,1:name=systemd:/system.slice/mnt-media-scratch.mount > rpc.statd --no-notify > > [root@jimmy nfs-utils]$ systemctl status mnt-media-scratch.mount > ● mnt-media-scratch.mount - /mnt/media/scratch > Loaded: loaded (/etc/fstab) > Active: inactive (dead) since Mon 2015-01-12 09:58:52 GMT; 1min 12s ago > Where: /mnt/media/scratch > What: marley.rasta.guthr.ie:/mnt/media/scratch > Docs: man:fstab(5) > man:systemd-fstab-generator(8) > > Jan 07 14:55:13 jimmy mount[3216]: /usr/sbin/start-statd: line 8: > systemctl: command not found > Jan 07 14:55:14 jimmy rpc.statd[3256]: Version 1.3.0 starting > Jan 07 14:55:14 jimmy rpc.statd[3256]: Flags: TI-RPC > [root@jimmy nfs-utils]$ Again this is fixed with the latest nfs-utils... Question? Why are you using v3 mounts? With V4 all this goes away. steved. > > > As you can see the mount is dead but the process is still running and > the systemctl status output does not correctly show the status of > binaries running in the cgroup. When the mount is active the process > does actually exist in this unit's context (provided systemd is used to > do the mount - if you call "mount /path" command separately, the > rpc.statd process can end up in weird cgroups - such as your user session!) > > Anyway, assuming the process is in the .mount unit cgroup, should > systemd detect the umount and kill the processes accordingly, and if > not, should calling "systemctl status" on .mount units show processes > even if it's in an inactive state? > > This is with 217 with a few cherry picks on top so might have been > addressed by now. > > > Cheers > > Col > _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel