From patchwork Fri May 26 02:46:43 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: NeilBrown X-Patchwork-Id: 9749629 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 6B52F60249 for ; Fri, 26 May 2017 02:46:57 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 583B128236 for ; Fri, 26 May 2017 02:46:57 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 4CA3C28307; Fri, 26 May 2017 02:46:57 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, T_TVD_MIME_EPI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 26D9728236 for ; Fri, 26 May 2017 02:46:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1425499AbdEZCqy (ORCPT ); Thu, 25 May 2017 22:46:54 -0400 Received: from mx2.suse.de ([195.135.220.15]:40628 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S943310AbdEZCqx (ORCPT ); Thu, 25 May 2017 22:46:53 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id BFF9EAC30; Fri, 26 May 2017 02:46:51 +0000 (UTC) From: NeilBrown To: systemd-devel@freedesktop.org, linux-nfs@vger.kernel.org Date: Fri, 26 May 2017 12:46:43 +1000 Subject: systemd and NFS "bg" mounts. Message-ID: <87lgpkgwrw.fsf@notabene.neil.brown.name> MIME-Version: 1.0 Sender: linux-nfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 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;