Bug#847204: nfs-kernel-server: `systemctl status` incorrectly reports server "active" even if not started
On 12/18/2016 11:41 PM, Michael Biebl wrote:
> On Tue, 6 Dec 2016 15:15:12 +0100 Riccardo Murri
> <riccardo.murri@gmail.com> wrote:
>>
>> Package: nfs-kernel-server
>> Version: 1:1.2.8-9
>>
>> The systemd service unit file for `nfs-kernel-server` incorrectly
>> reports the service status as "active" even when the NFS server is *not*
>> running (e.g., empty exports file).
>
> ..
>
>> debian@debian-nfs-bug:~$ sudo systemctl status nfs-kernel-server.service
>> * nfs-kernel-server.service - LSB: Kernel NFS server support
>> Loaded: loaded (/etc/init.d/nfs-kernel-server)
>> Active: active (exited) since Tue 2016-12-06 12:12:58 UTC; 1min 36s ago
>>
>> Dec 06 12:12:58 debian-nfs-bug nfs-kernel-server[1544]: Not starting NFS kernel daemon: no exports. ... (warning).
>> Dec 06 12:12:58 debian-nfs-bug systemd[1]: Started LSB: Kernel NFS server support.
>> Dec 06 12:14:33 debian-nfs-bug systemd[1]: Started LSB: Kernel NFS server support.
>
> The problem is, that nfs-kernel-server in jessie is a sysv init script.
> For those, systemd creates a wrapper unit which uses RemainAfterExit=yes
> as systemd can not know, if the init script starts a long running
> process or not.
>
> (that's why it shows "active (exited)" instead of "active (running)")
>
> The obvious solution is to use a native .service file, where you can set
> the proper Type=. This is the case for stretch.
On Stretch this doesn't help though, because of the way the NFS kernel
server works.
On Jessie (and before) the nfs-kernel-server init script would start
all sorts of daemons (such as rpc.svcgssd) that are auxiliary to the
NFS server, but at least for NFSv4 the NFS server itself is a kernel
thread.
It is started via rpc.nfsd $N, which tells the kernel to start $N
kernel threads, and then exits immediately. It stops via rpc.nfsd 0.
The problem here is that there's no userland process that is kept
running here. So that means that the systemd service also has to
have RemainAfterExit=yes to make this work.
And indeed, the upstream systemd unit (which will be used by the
Debian package in Stretch) indeed has that setting set:
https://sources.debian.net/src/nfs-utils/1:1.3.4-2/systemd/nfs-server.service/
I haven't tested the Stretch package yet, so I don't know how that
reacts to an empty /etc/exports, so maybe this specific bug doesn't
occur there any more.
However, if something else manually calls rpc.nfsd 0 during operation,
the service will be stopped, but systemd won't recognize it.
That all said, for the empty /etc/exports case, for Jessie alone:
> For jessie, that change would most likely be too invasive though,
A workaround for Jessie could be to create a file
/etc/systemd/system/nfs-kernel-server.d/stop-if-empty-exports.conf
with the following contents:
[Service]
ExecStartPost=/usr/local/sbin/stop_nfs_systemd_service_if_no_exports.sh
And the contents of that script being something like:
#!/bin/sh
if ... same check as in the init script that /etc/exports is empty ... ; then
# Enqueue a job for systemd to stop the service
systemctl stop --no-block nfs-kernel-server.service
fi
(For the Debian package one would obviously use different directories
for these files.)
This won't fix the problem entirely, but at least after boot the
nfs server will be considered stopped.
Regards,
Christian
Reply to: