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@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@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@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/ _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel