| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
Commit 9d4fc3fb added Wants=network-online.target which
is not enough to ensure the network is completely up
before the NFS server is started. After=network-online.target
is also needed.
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1419351
Signed-off-by: Steve Dickson <steved@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There has been an number startup problems where parts of
the NFS server fails to start due to DNS and other
parts of the network not be up.
Reading the systemd.special it seems network.target is
a passive unit which does not wait for the entire
network to come up and network-online.target is an
active unit which does wait.
So this adds Wants=network-online.target to all of
the NFS server services
Signed-off-by: Steve Dickson <steved@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There has been an number startup problem where parts of
the NFS server fail to start due to DNS and other
parts of the network not be up.
Reading the systemd.special it seems network.target is
a passive unit which does not wait and network-online.target
is an active unit which does not wait so that
should be used.
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1419351
Signed-off-by: Steve Dickson <steved@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now that we have /etc/nfs.conf, a lot of configuration can be
read directly. So nfs-config isn't really needed any more.
Some distributions allow command-line arguments for various
daemons to be set in an environment file (/etc/sysconfig,
/etc/defaults).
Passing these through /etc/nfs.conf is not possible.
Instead, a distro that needs this functionality can create drop-in
files which select the required value. As no commands are given
default arguments by systemd unit files, the drop-in can just add
distro-specific args.
For example
/lib/systemd/system/nfs-mountd.service.d/local.conf
[Service]
EnvironmentFile=/etc/sysconfig/nfs
ExecStart=
ExecStart=/usr/sbin/rpc.mountd $RPCMOUNTDOPTS
Note the need for the empty assignment to remove existing definitions
first.
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit: 1e41488f428c ("systemd: Order NFS server before client")
added an ordering dependency between network mounts and nfs-server.
This is good for loop-back NFS mounts as it ensures the server
will remain until after the mountpoint is unmounted.
However is is bad for _net mounts (such as those via iSCSI) which
are being NFS exported.
nfs-server needs to be start *after* exported filesystems are mounted,
and *before* NFS filesystems are mounted. systemd isn't able to make
this distinction natively, so we need to help it.
This patch adds a systemd generator which creates a drop-in for
nfs-server.services so that it is started "Before" any "nfs" or "nfs4"
mount, and so that it has a "RequiresMountsFor" dependency on any
exported filesystem. This creates the required ordering.
Note that if you try to export an "nfs" mount, systemd will detect an
ordering loop and will refused to start the nfs server. This is
probably the correct thing to do.
This patch also removes the ordering dependency with
remote-fs-pre.target which the above-mentioned commit added. It is no
longer needed.
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <neilb@suse.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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 <steved@redhat.com>
|
| |
|
|
|
|
|
|
| |
To trigger the systemd socket activation support
in rpcbind, nfs-service needs to Requires/After
rpcbind.service instead of rpbind.target
Signed-off-by: Steve Dickson <steved@redhat.com>
|
| |
|
|
|
|
|
|
|
|
| |
Stop depending on basic.target in the daemons which still do;
i. e. add DefaultDependencies=no. This makes it possible to
run NFS during early boot, and helps if you e. g. have /var
on NFS. We don't require much else than local-fs.
Acked-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
| |
|
|
|
|
|
|
|
| |
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.
Signed-off-by: Steve Dickson <steved@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With this patch either gssproxy or rpc.svcgssd are started only if the
auth module is requested, and it finds a keytab.
If the wants are in the main nfs-client or nfs-server unit files then
the two deamons are started unconditionally and would require
conditions which we can test once and for all in a single unit file
instead.
Change also Before and After statments accordingly to properly
serialize loading modules and starting daemons in 3 steps
1. load kernel GSS auth module
2. start GSS handling daemons
3. start NFS client/server daemons
Signed-off-by: Simo Sorce <simo@redhat.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When kernel have gssproxy support the the gssproxy
daemon should be used to manage the GSSAPI creds.
So this patch adds "calls" to the gssproxy daemon
from the NFS server systemd unit file.
When gssproxy is installed, gssproxy will be start
and rpc.svcgssd will not be. When gssproxy is not
installed the rpc.svcgssd daemon will be started.
Note, there are already existing hooks in the
rpc-svcgssd service file that will ensure the
gssproxy will be started before rpc.svcgssd
which allows the script not to start rpc.svcsdd
when gssproxy is installed and running.
Signed-off-by: Steve Dickson <steved@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We need to insert the auth_rpcgss module before starting rpc.svcgssd or
gss-proxy, for two reasons:
- gss-proxy needs access to the /proc/net/rpc/use-gss-proxy file
to set up communication with knfsd.
- the unit files need to able to test for the existance of the
same path in order to decide whether the kernel supports
gss-proxy or not.
Currently we're using dependencies on proc-fs-nfsd.mount for this, but
that works only because of the nfsd kernel module references some
symbols in auth_rpcgss, which is an odd implementation detail we're
likely to fix some day.
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
| |
|
|
|
|
|
|
|
| |
Instead of processing the config information into command lines every
time it might be needed, do it once in a separate service that other
services can Want.
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
| |
|
|
|
|
|
|
| |
This line was somehow missed in a recent patch. nfs-server.target
doesn't exists, so nothing can be part of it.
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With systemd, a 'service' should run a single server while a 'target'
can be used to group services.
As nfs service is really a group of services a 'target' makes more
sense.
However that means that we need commands like
systemctl start nfs-server.target
rather than the more simple
systemctl start nfs-server
As the target/service separate doesn't bring any gain except a minor
aesthetic, and does bring a practical inconvenience, this patch merges
nfs-server.target into nfs-server.service.
Reported-by: Steve Dickson <SteveD@redhat.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
DefaultDependencies should be "yes" (the default) for things
needed only be the NFS server, as that is a service that doesn't
need to start early.
DefaultDependencies should be "no" for things needed to mount an
NFS filesystem, and filesystems are mounted before basic.target.
To ensure these services are shut down in a timely fashion, they
must Conflict with systemd.umount so they are shutdown when everything
is unmounted.
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
Signed-off-by: Steve Dickson <steved@redhat.com>
|
