[systemd-devel] [PATCH] nfs.man: document incompatibility between "bg" option and systemd.

NeilBrown neilb at suse.com
Thu Jun 8 21:54:09 UTC 2017

On Thu, Jun 08 2017, J. Bruce Fields wrote:

> On Thu, Jun 08, 2017 at 03:16:52PM +1000, NeilBrown wrote:
>> So I think I've found a solution for systemd to handle "bg" nfs mounts
>> correctly.   I'll submit some pull requests for consideration.
> Out of curiosity, after that change is there still any reason you'd
> recommend any new user actually use "bg" (as opposed to an automount)?

Me? Recommend?  Who would listen?  Who would even hear?
For the last few years I've been recommending that automount should
be used for *all* NFS mounts at every opportunity.  I think I've had two

But no, I would not recommend "bg".  I would recommend automount and
then when they reported problems,  I would help fix them.

I would be much happier recommending automount if it were easier.
Setting up /etc/auto.direct with automountd is fairly easy, but you need
to actually enable it but modifying auto.master or auto.master.d, which
is slightly annoying.

systemd does make it easier to do direct mounts, but it is ugly.
You need to include "comment=systemd.automount" or "x-systemd.automount"
in /etc/fstab instead of just "automount" or "ondemand".  I understand
exactly why they did that and I cannot fault the logic.  But it still
looks clumsy.

With systemd, you cannot divorce the timeout that an application has to
wait when accessing the mountpoint while the server is down, from the
timeout imposed on the mount program.  i.e., mount cannot keep trying
in the background. - that could be useful if you want really-short
timeouts... at least it seems to me that they should be separate.

The timeout is configured differently if mounting from a device, or
mounting from anything else such as NFS.  The first uses
x-systemd.device-timeout.  The other needs x-systemd.mount-timeout.

But I'm ranting... I should probably shut up and send patches.
A generator for /etc/fstab.auto??

> I appreciate the effort to keep existing systems working, I'm just
> curious.

Compatibility with existing practice is certainly the main driver.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20170609/d084da7c/attachment.sig>

More information about the systemd-devel mailing list