Bug 1961322 - rpc.gssd is not restarted after package upgrade
Summary: rpc.gssd is not restarted after package upgrade
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: nfs-utils
Version: 35
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Steve Dickson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-05-17 17:16 UTC by Andreas Hasenack
Modified: 2022-12-13 15:23 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2022-12-13 15:23:27 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Andreas Hasenack 2021-05-17 17:16:11 UTC
Description of problem:
On an NFSv4 client, using sec=krb5 for the NFSv4 mount, the rpc.gssd daemon is needed. As far as I can tell, it's started as part of the nfs-client.target target, but it's a bit fuzzy (nfs-utils.service also deals with it). In any case, it's not meant to be enabled on its own, as it has no [Install] section.

If you then upgrade the nfs-utils rpm, it's expected that it should restart the services that are already running, but that doesn't seem to happen. I tested with fedora 33, 34, and now rawhide. They all have a postinst that tries to restart nfs-client.target. In rawhide it's a bit different in that it sets a marker, but other than that, f33 and f34 just used try-restart. Here is rawhide's nfs-utils postuninstall for the upgrade case:
postuninstall scriptlet (using /bin/sh):


if [ $1 -ge 1 ] && [ -x /usr/bin/systemctl ]; then
        # Package upgrade, not uninstall 
        for unit in nfs-client.target; do
                /usr/bin/systemctl set-property $unit Markers=+needs-restart || :
        done
fi


That currently fails with (below is debug output from dnf reinstall nfs-utils):
D: %postun(nfs-utils-1:2.5.3-3.rc2.fc35.x86_64): execv(/bin/sh) pid 808
+ '[' 1 -ge 1 ']'
+ '[' -x /usr/bin/systemctl ']'
+ for unit in nfs-client.target
+ /usr/bin/systemctl set-property nfs-client.target Markers=+needs-restart
Not supported unit type
+ :
+ '[' 1 -ge 1 ']'
+ '[' -x /usr/bin/systemctl ']'
+ for unit in nfs-server
+ /usr/bin/systemctl set-property nfs-server Markers=+needs-restart

But even if I try a restart (instead of that property setting, new to rawhide), it won't touch rpc.gssd (bash prompt says f33 because that's the fedora version I started with testing, and then upgraded to 34 and now it's running rawhide):
[root@f33-client ~]# pidof rpc.gssd
447
[root@f33-client ~]# systemctl restart nfs-client.target
[root@f33-client ~]# pidof rpc.gssd
447
[root@f33-client ~]# 

What does restart it is, obviously, systemctl restart rpc-gssd.service, and restart nfs-utils.service:
[root@f33-client ~]# systemctl restart rpc-gssd.service
[root@f33-client ~]# pidof rpc.gssd
937
[root@f33-client ~]# systemctl restart nfs-utils.service
[root@f33-client ~]# pidof rpc.gssd
945
[root@f33-client ~]# 

nfs-utils.service is another service without an [Install] section, so it can't be enabled. But maybe that's what should be restarted instead of the target? Or did I miss enabling some service that I should have?


Version-Release number of selected component (if applicable):
nfs-utils-2.5.3-3.rc2.fc35.x86_64

How reproducible:
Always on upgrade.


Steps to Reproduce:
1. Configure NFSv4 kerberized mountpoint. Check that rpc.gssd is running, and that it also starts on its own on reboot
2. Take note of the rpc.gssd pid
3. Upgrade the nfs-utils package. Note that rpc.gssd was not restarted

Actual results:
rpc.gssd is not restarted after the nfs-utils package is upgraded.

Expected results:
rpc.gssd, if running, should be restarted after the package that ships it (nfs-utils) is upgraded.

Additional info:

Comment 1 Ben Cotton 2021-08-10 13:02:47 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 35 development cycle.
Changing version to 35.

Comment 2 Ben Cotton 2022-11-29 16:57:27 UTC
This message is a reminder that Fedora Linux 35 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 35 on 2022-12-13.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '35'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 35 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Comment 3 Ben Cotton 2022-12-13 15:23:27 UTC
Fedora Linux 35 entered end-of-life (EOL) status on 2022-12-13.

Fedora Linux 35 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.

If you can reproduce this bug against a currently maintained version of Fedora Linux
please feel free to reopen this bug against that version. Note that the version
field may be hidden. Click the "Show advanced fields" button if you do not see
the version field.

If you are unable to reopen this bug, please file a new report against an
active release.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.