Hello On 01/12/2015 05:37 AM, Colin Guthrie wrote: > 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. Why? This is why rpc.statd does not need to be started on the client default any more.
> > 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. I'm not seeing how remote-fs-pre.target is a sync point. Its only used by the nfs-client.target... > > 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. Why spread out the pain? I think the sync point we have right now mount.nfs calling start-statd works and keeps everything in one place. > > 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. WOW.. Granted I'm no systemd expert... what did you say?? :-) My apologies but I'm unable to parse the above paragraph at all! In the end, I'm all for making things go smoother but I've never been a fan of fixing something that's not broken... steved. > > 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 > > > > _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel