[systemd-devel] Running system services required for certain filesystems

[Steve Dickson]

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 at 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 at nfs.service+Before=systemd-fstype at nfs.service
> and all is well) - there shouldn't really be a strong need for any
> actual changes to systemd-fstype at .service (or any
> systemd-fstype at 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
> 
> 
> 
>