From patchwork Tue Mar 3 09:55:16 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Martin Pitt X-Patchwork-Id: 5920941 Return-Path: X-Original-To: patchwork-linux-nfs@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id BC59E9F380 for ; Tue, 3 Mar 2015 10:03:09 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id E6B49202B4 for ; Tue, 3 Mar 2015 10:03:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id CE5F8200E6 for ; Tue, 3 Mar 2015 10:03:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755043AbbCCKDE (ORCPT ); Tue, 3 Mar 2015 05:03:04 -0500 Received: from mail.piware.de ([37.120.164.117]:43282 "EHLO mail.piware.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752406AbbCCKDB (ORCPT ); Tue, 3 Mar 2015 05:03:01 -0500 X-Greylist: delayed 463 seconds by postgrey-1.27 at vger.kernel.org; Tue, 03 Mar 2015 05:03:01 EST Received: by localhost.localdomain (Postfix, from userid 1000) id 2480711914E; Tue, 3 Mar 2015 10:55:16 +0100 (CET) Date: Tue, 3 Mar 2015 10:55:16 +0100 From: Martin Pitt To: linux-nfs@vger.kernel.org Subject: [PATCH] systemd: Order NFS server before client Message-ID: <20150303095516.GB3219@piware.de> MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-nfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, T_RP_MATCHES_RCVD, T_TVD_MIME_EPI, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Hello all, I'm currently systemd-ifying our nfs-utils Ubuntu package. For testing I put the NFS server and client (i. e. localhost:/foo/bar mounts) on the same machine. With that I get long hangs during shutdown on stopping the NFS .mount units, as when that happens the NFS server is already shut down. This is certainly a corner case as you'd usually not NFS-mount a share from localhost; but fixing it is relatively simple with the attached patch which makes sure that if NFS server and client are installed, the server starts before the client, and the client stops before the server. For a client without installed server this is harmless as Before= does not imply a dependency. Likewise, for an NFS server which does not mount shares by itself, it's also a no-op as remote-fs.target is empty. This would only slightly reorder the boot sequence for machines which both are an NFS server and have some remote NFS mounts, but I don't see an issue with that. Thanks for considering, Martin From d8c1fcce6d06aa062315a47134e8e3b364cb0700 Mon Sep 17 00:00:00 2001 From: Martin Pitt Date: Tue, 3 Mar 2015 10:45:38 +0100 Subject: [PATCH] systemd: Order NFS server before client This makes mounting NFS shares from localhost work reliably, as you need to start the server before attempting (client) mounts, and conversely on shutdown need to unmount all shares before stopping the server to avoid hangs. --- systemd/nfs-server.service | 3 +++ 1 file changed, 3 insertions(+) diff --git a/systemd/nfs-server.service b/systemd/nfs-server.service index 8010aad..b35e193 100644 --- a/systemd/nfs-server.service +++ b/systemd/nfs-server.service @@ -13,6 +13,9 @@ Before= rpc-statd-notify.service Wants=auth-rpcgss-module.service After=rpc-gssd.service gssproxy.service rpc-svcgssd.service +# start/stop server before/after client +Before=remote-fs-pre.target + Wants=nfs-config.service After=nfs-config.service -- 2.1.4