All of lore.kernel.org
 help / color / mirror / Atom feed
From: NeilBrown <neilb@suse.com>
To: systemd-devel@freedesktop.org, linux-nfs@vger.kernel.org
Subject: systemd and NFS "bg" mounts.
Date: Fri, 26 May 2017 12:46:43 +1000	[thread overview]
Message-ID: <87lgpkgwrw.fsf@notabene.neil.brown.name> (raw)

[-- Attachment #1: Type: text/plain, Size: 4491 bytes --]


Hi all,
 it appears that systemd doesn't play well with NFS "bg" mounts.
 I can see a few options for how to address this and wonder if anyone
 has any opinions.

 "bg" mounts will try to mount the filesystem just like normal, but
 if the server cannot be contacted before a "major timeout" (4.5 minutes
 by default for TCP), mount.nfs will fork and continue in the
 background.  Meanwhile the original mount process reports success (even
 though the filesystem wasn't mounted).  This allows the boot process to
 continue and succeed.

 Currently if you specify the "bg" option in /etc/fstab and are using
 systemd, the "bg" has no useful effect.
 systemd imposes its own timeout of 90 seconds (which is less than 4.5
 minutes).
 After 90 seconds, systemd will kill the mount process and decide that
 the mount failed.  This will lead to remote-fs.target not being reached,
 and boot not completing.

 If you set TimeoutSec=0 (aka "infinity") for the mount unit, either by
 hacking fstab-generator or adding "x-systemd.mount-timeout=infinity"
 if you have systemd 233 or later, then systemd won't kill the mount
 process, and after 4.5 minutes it will exit.
 (to quote a comment in systemd/src/core/mount.c
    " /bin/mount lies to us and is broken"
  :-)

 This is better, but the background mount.nfs can persist for a long
 time.  I don't think it persists forever, but at least half an hour I
 think.

 When the foo.mount unit is stopped, the mount.nfs process isn't killed.
 I don't think this is a major problem, but it is unfortunate and could
 be confusing.  During testing I've had multiple mount.nfs background
 processes all attached to the one .mount unit.

 What should we do about bg NFS mounts with systemd?
 Some options:
   - declare "bg" to be not-supported.  If you don't need the filesystem
     to be present for boot, then use x-systemd.automount, or some other
     automount scheme.
     If we did this, we probably need to make it very obvious that "bg"
     mounts aren't supported - maybe a log message that appears when
     you do "systemctl status ..." ??

   - decide that "bg" is really just a lame attempt at automounting, and
     that now we have real automounting, "bg" can be translated to that.
     So systemd-fstab-generator would treat "bg" like
     "x-systemd.automount" and otherwise strip it  from the list of
     options.

   - do our best to really support "bg".  That means, at least, applying
     a much larger timeout to "bg" mounts, and preferably killing any
     background processes when a mount unit is stopped.  Below is a
     little patch which does this last bit, but I'm not sure it is generally
     safe.

 A side question is: should this knowledge about NFS be encoded in
 systemd, or should nfs-utils add the necessary knowledge?

 i.e. we could add an nfs-fstab-generator to nfs-utils which creates
 drop-ins to modify the behaviour of the drop-ins provided by
 systemd-fstab-generator.
 Adding the TimeoutSec= would be easy.  Stripping the "bg" would be
 possible.
 Changing the remote-fs.target.requires/foo.mount symlink to be
 remote-fs.target.requires/foo.automount would be problematic though.
     
 Could we teach systemd-fstab-generator to ignore $TYPE filesystems
 if TYPE-fstab-generator existed?

 Or should we just build all this filesystem-specific knowledge into
 systemd?

Thanks for your thoughts,
NeilBrown


hackish patch to kill backgrounded mount.nfs processes:

diff --git a/src/core/mount.c b/src/core/mount.c
index ca0c4b0d5eed..91939b48d11a 100644
--- a/src/core/mount.c
+++ b/src/core/mount.c
@@ -883,6 +883,18 @@ static void mount_enter_unmounting(Mount *m) {
                     MOUNT_UNMOUNTING_SIGKILL))
                 m->n_retry_umount = 0;
 
+        if (m->result == MOUNT_SUCCESS &&
+            !m->from_proc_self_mountinfo) {
+                /* There is no mountpoint, but mount seemed to succeed.
+                 * Could be a bg mount.nfs.
+                 * In any case, kill any processes that might be hanging
+                 * around, they cannot be doing anything useful.
+                 */
+                sd_bus_error error = SD_BUS_ERROR_NULL;
+                unit_kill_common(UNIT(m), KILL_ALL, SIGTERM, -1, -1, &error);
+        }
+
+
         m->control_command_id = MOUNT_EXEC_UNMOUNT;
         m->control_command = m->exec_command + MOUNT_EXEC_UNMOUNT;
 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

             reply	other threads:[~2017-05-26  2:46 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-26  2:46 NeilBrown [this message]
2017-05-29 13:38 ` [systemd-devel] systemd and NFS "bg" mounts Lennart Poettering
2017-05-29 22:05   ` NeilBrown
2017-05-29 22:19   ` [PATCH] nfs.man: document incompatibility between "bg" option and systemd NeilBrown
2017-05-30  4:47     ` Niels de Vos
2017-05-30  7:40     ` [systemd-devel] " Michael Biebl
2017-05-30  8:55       ` NeilBrown
2017-05-30  9:15         ` Michael Biebl
2017-05-30 12:45           ` Lennart Poettering
2017-05-30 12:43     ` Lennart Poettering
2017-06-06 18:07     ` Steve Dickson
2017-06-06 19:57       ` [systemd-devel] " Michael Biebl
2017-06-07  8:13         ` Lennart Poettering
2017-06-07  9:42           ` Steve Dickson
2017-06-06 21:49       ` NeilBrown
2017-06-07 10:08         ` Steve Dickson
2017-06-07 12:02           ` Lennart Poettering
2017-06-07 19:48             ` Steve Dickson
2017-06-08  5:16               ` NeilBrown
2017-06-08 15:36                 ` J. Bruce Fields
2017-06-08 21:54                   ` NeilBrown
2017-06-08 20:24                 ` Steve Dickson
2017-06-07  8:12       ` Lennart Poettering
2017-06-07 10:04         ` Steve Dickson
2017-06-07 16:08           ` J. Bruce Fields
2017-06-08 20:34             ` Steve Dickson
2017-07-04 22:20     ` NeilBrown
2017-07-10 15:26       ` Steve Dickson
2017-07-10 22:56         ` NeilBrown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87lgpkgwrw.fsf@notabene.neil.brown.name \
    --to=neilb@suse.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=systemd-devel@freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.