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

[Colin Guthrie]

Colin Guthrie wrote on 12/01/15 10:37:
> So, overall is remote-fs-pre.target sufficient here, or should we look
> into supporting this in a more hotplug/JIT friendly way?

Digging into this further, I actually notice a problem with
remote-fs-pre.target, at least on my system.

It seems that it's not activated here any longer, despite me having
remote-fs.target enabled and, as remote-fs-pre.target is static, I
cannot specifically enable it. It's my understanding that it should be
automatically started.

Also, in an unrelated issue, remote-fs.target seems to be reached
*before* my actual remote fs's are mounted.

This all seems a little wrong (although correct in the sense that I am
using the nofail option which is what triggers this lack of waiting)

After a fresh boot here (note specifically how remote-fs-pre.target is
not active and that the rhome.mount is reached about 40 seconds after
remote-fs.target is reached):


[colin at jimmy systemd (master)]$ systemctl status rhome.mount
remote-fs.target remote-fs-pre.target network.target nfs-lock.service
● rhome.mount - /rhome
   Loaded: loaded (/etc/fstab)
   Active: active (mounted) since Mon 2015-01-12 10:44:24 GMT; 19min ago
    Where: /rhome
     What: nfs:/home/
     Docs: man:fstab(5)
           man:systemd-fstab-generator(8)
  Process: 19065 ExecMount=/bin/mount -n nfs:/home/ /rhome -t nfs -o
_netdev,nfsvers=3,nofail,user,tcp,rsize=8192,wsize=8192,soft
(code=exited, status=0/SUCCESS)

● remote-fs.target - Remote File Systems
   Loaded: loaded (/usr/lib/systemd/system/remote-fs.target; enabled)
   Active: active since Mon 2015-01-12 10:43:44 GMT; 19min ago
     Docs: man:systemd.special(7)

● remote-fs-pre.target - Remote File Systems (Pre)
   Loaded: loaded (/usr/lib/systemd/system/remote-fs-pre.target; static)
   Active: inactive (dead)
     Docs: man:systemd.special(7)

● network.target - Network
   Loaded: loaded (/usr/lib/systemd/system/network.target; static)
   Active: active since Mon 2015-01-12 10:44:24 GMT; 19min ago
     Docs: man:systemd.special(7)
           http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget

● nfs-lock.service - NFS file locking service.
   Loaded: loaded (/usr/lib/systemd/system/nfs-lock.service; static)
   Active: active (running) since Mon 2015-01-12 10:44:24 GMT; 19min ago
  Process: 19099 ExecStart=/sbin/rpc.statd $STATDARGS (code=exited,
status=0/SUCCESS)
  Process: 19074
ExecStartPre=/usr/libexec/nfs-utils/scripts/nfs-lock.preconfig
(code=exited, status=0/SUCCESS)
 Main PID: 19101 (rpc.statd)
   CGroup: /system.slice/nfs-lock.service
           └─19101 /sbin/rpc.statd


On my system I think nfs-lock.service was probably started by the (now
fixed) horrible /usr/sbin/start-statd callout script implemented in
mount.nfs.

I do have nfs-lock unit specified with Before=remote-fs-pre.target, so
in the past it was started before any mounts were attempted, but now it
doesn't start it might not be activated until later.

I'm not sure but is this just a bug in fstab-generator? i.e. Shouldn't
it put a Requires+After=remote-fs-pre.target in it's generated .mount
units for those mounts that are determined to be remote? (neither of
which are present here)

Or am I missing something?

What else is meant to pull in remote-fs-pre.target? The only mention in
the code is in src/core/mount.c but that's just for an After= dep, not a
Requires= one.

Perhaps the fstab-generator just needs a Requires= dep and mount.c takes
care of the After= bit?

I don't see any specific commits to fstab-generator since v217 which is
what I'm using.

This is my generated unit:

[colin at jimmy systemd (master)]$ cat /run/systemd/generator/rhome.mount
# Automatically generated by systemd-fstab-generator

[Unit]
SourcePath=/etc/fstab
Documentation=man:fstab(5) man:systemd-fstab-generator(8)

[Mount]
What=nfs:/home/
Where=/rhome
Type=nfs
Options=_netdev,nfsvers=3,nofail,user,tcp,rsize=8192,wsize=8192,soft

And the other deps that are added in memory only (not sure why they are
not just encoded into the generated .mount unit).

[colin at jimmy systemd (master)]$ systemctl show rhome.mount| grep -Ei
"before|after|want|require"
Requires=-.mount
Wants=network-online.target system.slice
WantedBy=remote-fs.target
Before=umount.target
After=systemd-journald.socket remote-fs-pre.target network.target
network-online.target system.slice -.mount
RequiresMountsFor=/






Going back to the fact that remote-fs.target starts before the mounts
due to my use of nofail, this is the offending line in fstab-generator:

        if (post && !noauto && !nofail && !automount)
                fprintf(f, "Before=%s\n", post);

In an ideal world, I'd still like remote-fs.target (aka "post") to wait,
but I can see why local-fs.target should not wait (when post contains
that value).

e.g. I'd like remote-fs.target to be reached eventually, but only after
the mount jobs have timed out

Would a condition of:

        if (post && !noauto && (!nofail || streq(post,
SPECIAL_REMOTE_FS_TARGET) && !automount)
                fprintf(f, "Before=%s\n", post);

be permissible here or would there be other consequences?

I know there's still a "point in time" based issue here generally, and
it would introduce a slight asymmetry between local-fs and remote-fs
targets with regard to their nofail handling, but perhaps it's justified?

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/