Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
From:   Andreas Hasenack <andreas@canonical.com>
Date:   Tue, 25 May 2021 10:34:07 -0300
Message-ID: <CANYNYEGAK84yoQ2wDdpQPpaYcBFVo-LAcU7pvEo7H_BVqX1gLg@mail.gmail.com>
Subject: rpc.gssd does not restart after package upgrade
To:     linux-nfs@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Hi,

this would normally be just a linux distribution bug, and it is, but
it looks like the systemd service files and targets all come from
upstream.

While testing the fix for
https://bugzilla.redhat.com/show_bug.cgi?id=1419280 in Ubuntu, I
noticed that rpc.gssd was not being restarted in post (same thing
happens in debian). It looks like the nfs-utils.service service was
created for this task, but it has no [install] section, so it can't be
enabled. Long story short, in ubuntu/debian it's only restarted in
post if it was started before.

I then checked Fedora 33, 34 and rawhide, and saw that there it's also
not restarted, but with a tweak: the rpms try to restart
nfs-client.target, which also doesn't seem to work on a running
system, but maybe I did something wrong in enabling nfs there in the
first place (maybe I forgot to enable one of the services?). In any
case, I filed https://bugzilla.redhat.com/show_bug.cgi?id=1961322 for
that with more details.

In ubuntu I'll probably work around it by just calling "systemctl
start nfs-utils.service" in post, before the restart routines kick in
(still testing that for side effects), but since the service files
come from upstream, and the intention seemed to be for this exact
purpose (restart on pkg upgrade), I'm sending this email here looking
for guidance on how it was intended for packagers to restart all the
myriad of nfs v2/v3/v4 services on upgrade.

Thanks!