Hi, On a related note to my previous message (subject "systemctl status not showing still running processes in inactive .mount unit cgroups (NFS specifically)"), when mount.nfs runs to mount NFS filesystems, it shells out to /usr/sbin/start-statd which in turn calls sytemctl to start rpc.statd service. This feels ugly.
We have a sync point for this in the form of remote-fs-pre.target, but for some reason upstream nfs-utils people still deem that /usr/sbin/start-statd is a required component. But it did get me thinking about how "clean" remote-fs-pre.target really is. We do need to make sure rpc.statd is running before any NFS filesystems are mounted and and relying on the blunt instrument of remote-fs-pre.target seems kinda wrong. It should be more "on demand" e.g. when I start an nfs mount, it should be able to specify that rpc.statd service is a prerequisite. So my question is, is there a cleaner way to have dependencies like this specified for particular FS types? With the goal being that before systemd will try and mount any NFS filesystems it will make sure that nfs-lock.service (or statd.service or nfs-statd.service or whatever it's name really should be) is running? I kinda want a Requires=nfs-lock.service and After=nfs-lock.service definitions to go into all my *.mount units for any nfs filesystem, but it a way that means I don't have to actually specify this manually in my fstab. Something like a pseudo service - systemd-fstype@nfs.service with Type=oneshot+RemainAfterExit=true+Exec=/usr/bin/true that is run by systemd before it does it mounting to act as a sync point (thus allowing nfs-lock.service to just put RequiredBy=systemd-fstype@nfs.service+Before=systemd-fstype@nfs.service and all is well) - there shouldn't really be a strong need for any actual changes to systemd-fstype@.service (or any systemd-fstype@nfs.service.d dropins) here, as it can all be specified "the other way around" in nfs-lock.service. But that said, using a ".service" unit as a sync point is fugly. That's what .targets are for, but we don't support (AFAIK) templated targets. So, overall is remote-fs-pre.target sufficient here, or should we look into supporting this in a more hotplug/JIT friendly way? (FWIW, I know we could extend the fstab-generator to include this in the generated .mount units, but baking such deps logic in there seems wrong anyway as it wouldn't apply to manual .mount units outside of fstab and it's not really where the dep info should live anyway). Thoughts Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel