Hello community,

here is the log from the commit of package nfs-utils for openSUSE:Factory 
checked in at 2016-06-02 12:48:50
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Comparing /work/SRC/openSUSE:Factory/nfs-utils (Old)
 and      /work/SRC/openSUSE:Factory/.nfs-utils.new (New)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Package is "nfs-utils"

Changes:
--------
--- /work/SRC/openSUSE:Factory/nfs-utils/nfs-utils.changes      2016-04-28 
16:50:52.000000000 +0200
+++ /work/SRC/openSUSE:Factory/.nfs-utils.new/nfs-utils.changes 2016-06-02 
12:48:51.000000000 +0200
@@ -1,0 +2,8 @@
+Tue May 24 22:27:14 UTC 2016 - nfbr...@suse.com
+
+- 0001-systemd-Decouple-the-starting-and-stopping-of-rpcbin.patch
+  0002-systemd-unit-files-fix-up-dependencies-on-rpcbind.patch
+ Fix systemd dependencies to ensure rpcbind is started when needed.
+ (bsc#975265)
+
+-------------------------------------------------------------------

New:
----
  0001-systemd-Decouple-the-starting-and-stopping-of-rpcbin.patch
  0002-systemd-unit-files-fix-up-dependencies-on-rpcbind.patch

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Other differences:
------------------
++++++ nfs-utils.spec ++++++
--- /var/tmp/diff_new_pack.j5Afze/_old  2016-06-02 12:48:52.000000000 +0200
+++ /var/tmp/diff_new_pack.j5Afze/_new  2016-06-02 12:48:52.000000000 +0200
@@ -66,6 +66,8 @@
 Patch5:         0001-close-the-syslog-fd-in-daemon_init.patch
 Patch6:         0001-mount.nfs-trust-the-exit-status-of-start_statd.patch
 Patch7:         0001-mount-run-START_STATD-fully-as-root.patch
+Patch8:         0001-systemd-Decouple-the-starting-and-stopping-of-rpcbin.patch
+Patch9:         0002-systemd-unit-files-fix-up-dependencies-on-rpcbind.patch
 
 Suggests:       python-base
 
@@ -124,6 +126,8 @@
 %patch5 -p1
 %patch6 -p1
 %patch7 -p1
+%patch8 -p1
+%patch9 -p1
 
 cp %{S:6} .
 

++++++ 0001-systemd-Decouple-the-starting-and-stopping-of-rpcbin.patch ++++++
>From 4fabfcd082069a16ea8769b9ea9344fc15011366 Mon Sep 17 00:00:00 2001
From: Steve Dickson <ste...@redhat.com>
Date: Mon, 9 Nov 2015 11:28:30 -0500
Subject: [PATCH] systemd: Decouple the starting and stopping of
 rpcbind/nfs-server

Commit b98f2af15 introduced a regression that cause the
starting and stop of rpcbind and the nfs-server to
be depended on each other

The starting of the NFS server should start rpcbind
but bring rpcbind down should not bring the NFS
server down.

Signed-off-by: Steve Dickson <ste...@redhat.com>
---
 systemd/nfs-server.service | 2 +-
 systemd/rpc-statd.service  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/systemd/nfs-server.service b/systemd/nfs-server.service
index 12b02f26f9ce..317e5d689767 100644
--- a/systemd/nfs-server.service
+++ b/systemd/nfs-server.service
@@ -1,7 +1,7 @@
 [Unit]
 Description=NFS server and services
 DefaultDependencies=no
-Requires= network.target proc-fs-nfsd.mount rpcbind.service
+Requires= network.target proc-fs-nfsd.mount rpcbind.target
 Requires= nfs-mountd.service
 Wants=rpc-statd.service nfs-idmapd.service
 Wants=rpc-statd-notify.service
diff --git a/systemd/rpc-statd.service b/systemd/rpc-statd.service
index 14604d783ddf..f16ea425dc77 100644
--- a/systemd/rpc-statd.service
+++ b/systemd/rpc-statd.service
@@ -3,7 +3,7 @@ Description=NFS status monitor for NFSv2/3 locking.
 DefaultDependencies=no
 Conflicts=umount.target
 Requires=nss-lookup.target rpcbind.target
-After=network.target nss-lookup.target rpcbind.target
+After=network.target nss-lookup.target rpcbind.service
 
 PartOf=nfs-utils.service
 
-- 
2.8.2

++++++ 0002-systemd-unit-files-fix-up-dependencies-on-rpcbind.patch ++++++
>From 91da135f243d6f87fcea8b8a3ce28a589917b0e4 Mon Sep 17 00:00:00 2001
From: NeilBrown <ne...@suse.com>
Date: Mon, 2 May 2016 08:54:13 -0400
Subject: [PATCH] systemd unit files: fix up dependencies on rpcbind.

The dependencies on rpcbind have been changed a few times and I think
they are still wrong.  So I'll go into some detail to justify this
change.

Firstly: rpcbind.target rpcbind.socket or rpcbind.service?

The systemd documentation talks about targets as "synchronization
points" and likens them to SysV init run levels.  Run levels are about
ordering but not dependencies.

The systemd.special man page describes rpcbind.target as intended
explicitly for ordering sysvinit scripts, with "After=" dependencies.

So while I think it is valid to use rpcbind.target for ordering
(before/after) it shouldn't be used for dependencies (Wants/Requires).
The rpcbind.target file included in systemd does not "Require" the
actual service, so requiring rpcbind.target itself is pointless.

I think we shouldn't use rpcbind.target at all.  Leave it for sysvinit
synchronization.

So: .socket or .service?

I think nfs only needs the socket to be active.  On first connection
the service will be started.  But nfs does not need to wait for the
service to start, only the socket.  So I think we should exclusively
use rpcbind.socket.

Next: Wants or Requires.

rpc.statd definitely Requires rpcbind.  It needs to register to be
useful, and without rpcbind it cannot register.

nfs-server does not necesarily require rpcbind.  Specifically if
configured for NFSv4 only, nfs-server will work quite happily without
rpcbind.

Someone with an NFSv4 only setup who wants rpcbind to not run can use
  systemctl mask rpcbind.socket
to ensure it never runs.
So nfs-server should only "Wants: rpcbind.socket".
I think
 Commit: 4fabfcd08206 ("systemd: Decouple the starting and stopping of
rpcbind/nfs-server")
should have changed "Requires" to "Wants" rather than "server" to
"target"
to fix the dependency problem.

Finally: After?

It only makes sense to declare an ordering relation as "After:"
something that will actually be started.  If "foo.service" is not part
of the systemd transaction, then "After: foo.service" has no effect.
So having:
  Requires: rpcbind.target
  After: rpcbind.socket

doesn't make much sense unless there is some relationship between
rpcbind.target and rpcbind.socket, and there is no general guarantee
of that (though what individual distros do, I don't know).
So the "After" should match the "Wants" or "Requires".

It might make sense to
  Requires: rpcbind.socket
  After: rpcbind.target

as it is reasonable to assume that rpcbind.target will be ordered with
rpcbind.socket, but as we can use rpcbind.socket explictly, that is
clearer.

So my conclusion is that nfs-server should:
  Wants: rpcbind.socket
  After: rpcbind.socket

and rpc-statd should
  Requires: rpcbind.socket
  After: rpcbind.socket

which is what this patch puts into effect.

Signed-off-by: NeilBrown <ne...@suse.com>
Signed-off-by: Steve Dickson <ste...@redhat.com>
---
 systemd/nfs-server.service | 5 +++--
 systemd/rpc-statd.service  | 4 ++--
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/systemd/nfs-server.service b/systemd/nfs-server.service
index 317e5d689767..2ccdc6344cd5 100644
--- a/systemd/nfs-server.service
+++ b/systemd/nfs-server.service
@@ -1,13 +1,14 @@
 [Unit]
 Description=NFS server and services
 DefaultDependencies=no
-Requires= network.target proc-fs-nfsd.mount rpcbind.target
+Requires= network.target proc-fs-nfsd.mount
 Requires= nfs-mountd.service
+Wants=rpcbind.socket
 Wants=rpc-statd.service nfs-idmapd.service
 Wants=rpc-statd-notify.service
 
 After= local-fs.target
-After= network.target proc-fs-nfsd.mount rpcbind.service nfs-mountd.service
+After= network.target proc-fs-nfsd.mount rpcbind.socket nfs-mountd.service
 After= nfs-idmapd.service rpc-statd.service
 Before= rpc-statd-notify.service
 
diff --git a/systemd/rpc-statd.service b/systemd/rpc-statd.service
index f16ea425dc77..a02f5c41a424 100644
--- a/systemd/rpc-statd.service
+++ b/systemd/rpc-statd.service
@@ -2,8 +2,8 @@
 Description=NFS status monitor for NFSv2/3 locking.
 DefaultDependencies=no
 Conflicts=umount.target
-Requires=nss-lookup.target rpcbind.target
-After=network.target nss-lookup.target rpcbind.service
+Requires=nss-lookup.target rpcbind.socket
+After=network.target nss-lookup.target rpcbind.socket
 
 PartOf=nfs-utils.service
 
-- 
2.8.2



Reply via email to