Bug 1527653
| Summary: | nfs-server.service should use systemctl rather than reading pidfile and kill | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Robbie Harwood <rharwood> |
| Component: | nfs-utils | Assignee: | Steve Dickson <steved> |
| Status: | CLOSED ERRATA | QA Contact: | Yongcheng Yang <yoyang> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.4 | CC: | herrold, rhandlin, rharwood, steved, xzhou, yoyang |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | nfs-utils-1.3.0-0.55.el7 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2018-10-30 11:48:04 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
(In reply to Robbie Harwood from comment #0) > nfs-server.service, in the [Service] section, contains this line: > > ExecStartPre=-/bin/sh -c '/bin/kill -HUP `cat /run/gssproxy.pid`' > > It would be better if instead it called `systemctl reload gssproxy` (or > `systemctl reload-or-restart gssproxy` if you prefer), which will accomplish > the same thing. > > I would of course prefer that this be resolved in Fedora first. However, > the unit file on Fedora doesn't appear to contain anything that resembles > this line. I am curious if that is also a bug, or if the code just behaves > differently there. How important is this? Can it wait for 7.6 or try to get it in 7.5? Sorry, forgot to set flag. It can wait. Hi Steve, would this issue wait for 7.6 or try to get in 7.5? Deferring to 7.6 now :) Looks like the nfs calls `systemctl restart gssproxy` instead of `reload` as comment #0 mentioned. It seems to result in the same consequences as expected. However, I don't know whether there's any concern about it. ~~~~~~~~~~~~~~~~~~~~~~~~ Checked with version -55 ~~~~~~~~~~~~~~~~~~~~~~~~ [root@test ~]# rpm -q nfs-utils nfs-utils-1.3.0-0.55.el7.x86_64 [root@test ~]# systemctl restart gssproxy ; systemctl status gssproxy -l ● gssproxy.service - GSSAPI Proxy Daemon Loaded: loaded (/usr/lib/systemd/system/gssproxy.service; disabled; vendor preset: disabled) Active: active (running) since Thu 2018-06-28 04:38:21 EDT; 5ms ago Process: 20836 ExecStart=/usr/sbin/gssproxy -D (code=exited, status=0/SUCCESS) Main PID: 20837 (gssproxy) <<<<<<<<<<<<<<<<<<<<<<<<<<<<<< CGroup: /system.slice/gssproxy.service └─20837 /usr/sbin/gssproxy -D Jun 28 04:38:21 test systemd[1]: Starting GSSAPI Proxy Daemon... Jun 28 04:38:21 test gssproxy[20836]: [2018/06/28 08:38:21]: Debug Enabled (level: 1) Jun 28 04:38:21 test gssproxy[20836]: [2018/06/28 08:38:21]: Problem with kernel communication! NFS server will not work Jun 28 04:38:21 test gssproxy[20836]: [2018/06/28 08:38:21]: Client connected (fd = 11)[2018/06/28 08:38:21]: (pid = 20837) (uid = 0) (gid = 0)[2018/06/28 08:38:21]: (context = system_u:system_r:kernel_t:s0)[2018/06/28 08:38:21]: Jun 28 04:38:21 test systemd[1]: Started GSSAPI Proxy Daemon. [root@test ~]# [root@test ~]# systemctl restart nfs ; systemctl status gssproxy -l ● gssproxy.service - GSSAPI Proxy Daemon Loaded: loaded (/usr/lib/systemd/system/gssproxy.service; disabled; vendor preset: disabled) Active: active (running) since Thu 2018-06-28 04:38:28 EDT; 10ms ago Process: 20890 ExecStart=/usr/sbin/gssproxy -D (code=exited, status=0/SUCCESS) Main PID: 20891 (gssproxy) <<<<<<<<<<<<<<<<<<<<< PID changes CGroup: /system.slice/gssproxy.service └─20891 /usr/sbin/gssproxy -D Jun 28 04:38:28 test systemd[1]: Starting GSSAPI Proxy Daemon... Jun 28 04:38:28 test gssproxy[20890]: [2018/06/28 08:38:28]: Debug Enabled (level: 1) Jun 28 04:38:28 test gssproxy[20890]: [2018/06/28 08:38:28]: Problem with kernel communication! NFS server will not work Jun 28 04:38:28 test gssproxy[20890]: [2018/06/28 08:38:28]: Client connected (fd = 11)[2018/06/28 08:38:28]: (pid = 20891) (uid = 0) (gid = 0)[2018/06/28 08:38:28]: (context = system_u:system_r:kernel_t:s0)[2018/06/28 08:38:28]: Jun 28 04:38:28 test systemd[1]: Started GSSAPI Proxy Daemon. [root@test ~]# ~~~~~~~~~~~~~~~~~~~~~~~~~~ Compared with previous -54 ~~~~~~~~~~~~~~~~~~~~~~~~~~ [root@test nfs]# rpm -q nfs-utils nfs-utils-1.3.0-0.54.el7.x86_64 [root@test nfs]# systemctl restart gssproxy ; systemctl status gssproxy -l ● gssproxy.service - GSSAPI Proxy Daemon Loaded: loaded (/usr/lib/systemd/system/gssproxy.service; disabled; vendor preset: disabled) Active: active (running) since Thu 2018-06-28 04:47:57 EDT; 6ms ago Process: 10725 ExecReload=/bin/kill -HUP $MAINPID (code=exited, status=0/SUCCESS) Process: 10894 ExecStart=/usr/sbin/gssproxy -D (code=exited, status=0/SUCCESS) Main PID: 10895 (gssproxy) <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< CGroup: /system.slice/gssproxy.service └─10895 /usr/sbin/gssproxy -D Jun 28 04:47:57 test systemd[1]: Starting GSSAPI Proxy Daemon... Jun 28 04:47:57 test gssproxy[10894]: [2018/06/28 08:47:57]: Debug Enabled (level: 1) Jun 28 04:47:57 test gssproxy[10894]: [2018/06/28 08:47:57]: Problem with kernel communication! NFS server will not work Jun 28 04:47:57 test gssproxy[10894]: [2018/06/28 08:47:57]: Client connected (fd = 11)[2018/06/28 08:47:57]: (pid = 10895) (uid = 0) (gid = 0)[2018/06/28 08:47:57]: (context = system_u:system_r:kernel_t:s0)[2018/06/28 08:47:57]: Jun 28 04:47:57 test systemd[1]: Started GSSAPI Proxy Daemon. [root@test nfs]# systemctl restart nfs ; systemctl status gssproxy -l ● gssproxy.service - GSSAPI Proxy Daemon Loaded: loaded (/usr/lib/systemd/system/gssproxy.service; disabled; vendor preset: disabled) Active: active (running) since Thu 2018-06-28 04:47:57 EDT; 7s ago Process: 10725 ExecReload=/bin/kill -HUP $MAINPID (code=exited, status=0/SUCCESS) Process: 10894 ExecStart=/usr/sbin/gssproxy -D (code=exited, status=0/SUCCESS) Main PID: 10895 (gssproxy) <<<<<<<<<<<<<<<<<< PID *not* changes CGroup: /system.slice/gssproxy.service └─10895 /usr/sbin/gssproxy -D Jun 28 04:47:57 test gssproxy[10894]: [2018/06/28 08:47:57]: Problem with kernel communication! NFS server will not work Jun 28 04:47:57 test gssproxy[10894]: [2018/06/28 08:47:57]: Client connected (fd = 11)[2018/06/28 08:47:57]: (pid = 10895) (uid = 0) (gid = 0)[2018/06/28 08:47:57]: (context = system_u:system_r:kernel_t:s0)[2018/06/28 08:47:57]: Jun 28 04:47:57 test systemd[1]: Started GSSAPI Proxy Daemon. Jun 28 04:48:05 test gssproxy[10894]: [2018/06/28 08:48:05]: Received SIGHUP; re-reading config. <<<<<<<<<<<<<< Jun 28 04:48:05 test gssproxy[10894]: [2018/06/28 08:48:05]: Keytab /etc/krb5.keytab has no content (-1765328203) Jun 28 04:48:05 test gssproxy[10894]: [2018/06/28 08:48:05]: Service: nfs-server, Enckey: [ephemeral], Enctype: 18 Jun 28 04:48:05 test gssproxy[10894]: [2018/06/28 08:48:05]: Keytab /etc/krb5.keytab has no content (-1765328203) Jun 28 04:48:05 test gssproxy[10894]: [2018/06/28 08:48:05]: Service: nfs-client, Enckey: [ephemeral], Enctype: 18 Jun 28 04:48:05 test gssproxy[10894]: [2018/06/28 08:48:05]: Debug Enabled (level: 1) Jun 28 04:48:05 test gssproxy[10894]: [2018/06/28 08:48:05]: New config loaded successfully. <<<<<<<<<<<<<<<<<<< [root@test nfs]# Moving to VERIFIED according to comment #8 Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2018:3311 |
nfs-server.service, in the [Service] section, contains this line: ExecStartPre=-/bin/sh -c '/bin/kill -HUP `cat /run/gssproxy.pid`' It would be better if instead it called `systemctl reload gssproxy` (or `systemctl reload-or-restart gssproxy` if you prefer), which will accomplish the same thing. I would of course prefer that this be resolved in Fedora first. However, the unit file on Fedora doesn't appear to contain anything that resembles this line. I am curious if that is also a bug, or if the code just behaves differently there. Thanks!