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

[Colin Guthrie]

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 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.

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/