Bug 1313721 - nfs-idmapd.service contains dependency on nfs-server.service on nfs client as well. The only service required at client end is nfs-idmapd. Looking at the /usr/lib/systemd/system/nfs-idmapd.service, it shows that it is binded to nfs-server.service.
nfs-idmapd.service contains dependency on nfs-server.service on nfs client a...
Status: CLOSED DUPLICATE of bug 1277801
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: nfs-utils (Show other bugs)
7.2
i386 Linux
unspecified Severity high
: rc
: ---
Assigned To: Steve Dickson
Filesystem QE
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-03-02 04:50 EST by Ashima Rawat
Modified: 2016-04-26 13:11 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-04-26 13:11:29 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ashima Rawat 2016-03-02 04:50:09 EST
Description of problem:

Restarting nfs-idmapd service is also restarting nfs-server.service as nfs-idmapd service is binded to nfs-server.service.

We can clearly see that nfs-idmapd.service is static which means that its dependent on other service.

[root@dhcp5-106 ~]# systemctl list-unit-files --type service|grep -i nfs
nfs-blkmap.service                          disabled
nfs-config.service                          static
nfs-idmap.service                           static
nfs-idmapd.service                          static
nfs-lock.service                            static
nfs-mountd.service                          static
nfs-secure-server.service                   static
nfs-secure.service                          static
nfs-server.service                          enabled
nfs-utils.service                           static
nfs.service                                 disabled
nfslock.service                             static

To determine what services are ordered to start before the specified service, here is the command and output:

[root@dhcp5-106 ~]# systemctl status nfs-idmapd.service
● nfs-idmapd.service - NFSv4 ID-name mapping service
   Loaded: loaded (/usr/lib/systemd/system/nfs-idmapd.service; static; vendor preset: disabled)
   Active: active (running) since Sun 2016-02-07 11:49:04 IST; 2 days ago
  Process: 554 ExecStart=/usr/sbin/rpc.idmapd $RPCIDMAPDARGS (code=exited, status=0/SUCCESS)  Main PID: 564 (rpc.idmapd)
   CGroup: /system.slice/nfs-idmapd.service
           └─564 /usr/sbin/rpc.idmapd

Feb 07 11:49:04 dhcp5-106.gsslab.pnq.redhat.com systemd[1]: Starting NFSv4 ID-name mapping service...
Feb 07 11:49:04 dhcp5-106.gsslab.pnq.redhat.com systemd[1]: Started NFSv4 ID-name mapping service.

To determine what services are ordered to start before the specified service, here is the command and output:

[root@dhcp5-106 ~]# systemctl list-dependencies --after nfs-idmapd.service nfs-idmapd.service ● ├─nfs-config.service ● ├─system.slice ● ├─systemd-journald.socket ● ├─var-lib-nfs-rpc_pipefs.mount ● └─local-fs.target
●   ├─-.mount
●   ├─boot.mount
●   ├─dm-event.service
●   ├─lvm2-monitor.service
●   ├─rhel-readonly.service
●   ├─sys-kernel-config.mount
●   ├─systemd-fsck-root.service
●   ├─systemd-remount-fs.service
●   └─local-fs-pre.target
●     ├─systemd-remount-fs.service
●     └─systemd-tmpfiles-setup-dev.service

To determine what services are ordered to start after the specified service, here is the command and output:

[root@dhcp5-106 ~]# systemctl list-dependencies --before nfs-idmapd.service nfs-idmapd.service ● └─nfs-server.service <----------here we can see nfs-server.service

There should be no need to start nfs-server.service @ nfs client end while restarting the nfs-idmapd.service.

The dependency should be removed.
Comment 2 Ashima Rawat 2016-03-09 19:43:47 EST
Hi,

Could you please let me know if there is anything being planned to fix this bug and if yes in which release ?

Thanks
Ashima
Comment 3 Harshula Jayasuriya 2016-03-14 21:43:29 EDT
My understanding is that we've moved to using nfsidmap on the NFS client instead of rpc.idmapd.
Comment 4 Steve Dickson 2016-03-30 16:57:04 EDT
(In reply to Harshula Jayasuriya from comment #3)
> My understanding is that we've moved to using nfsidmap on the NFS client
> instead of rpc.idmapd.

This is true... the client kernel does use an upcall
to nfsidmap to resolve id/gid for v4.X.... 

Why is restarting of rpc.idmapd evening happening?
Comment 5 Ashima Rawat 2016-04-05 01:53:39 EDT
In Red Hat Enterprise Linux 7, only the NFSv4 server uses rpc.idmapd. 
The NFSv4 client uses the keyring-based idmapper nfsidmap. nfsidmap is a stand-alone program that is called by the kernel on-demand to perform ID mapping; it is not a daemon. If there is a problem with nfsidmap does the client fall back to using rpc.idmapd. More information regarding nfsidmap can be found on the nfsidmap man page.

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Storage_Administration_Guide/ch-nfs.html
http://man7.org/linux/man-pages/man5/nfsidmap.5.html
Comment 6 Ashima Rawat 2016-04-05 07:50:00 EDT
Hi, 

In addition to my previous comment did some testing and below are the results:

Example :

-rw-r--r--. 1 nobody nobody 102400 Dec 22 12:00 test48
-rw-r--r--. 1 nobody nobody 102400 Dec 22 12:00 test49
-rw-r--r--. 1 nobody nobody 102400 Dec 22 12:00 test5
-rw-r--r--. 1 nobody nobody 102400 Dec 22 12:00 test50
-rw-r--r--. 1 nobody nobody 102400 Dec 22 12:00 test6
-rw-r--r--. 1 nobody nobody 102400 Dec 22 12:00 test7
-rw-r--r--. 1 nobody nobody 102400 Dec 22 12:00 test8
-rw-r--r--. 1 nobody nobody 102400 Dec 22 12:00 test9
-rw-r--r--. 1 nobody nobody    399 Jan 31 13:43 test.c
[root@arawat72 mnt]# vi /etc/idmapd.conf  <---- Added domain here
[root@arawat72 mnt]# nfsidmap -c
[root@arawat72 mnt]# ls -l
total 5248
-rw-------. 1 testuser tstgrp   6144 Dec 23 13:36 aquota.group
-rw-------. 1 testuser tstgrp   6144 Dec 23 13:36 aquota.user
-rw-r--r--. 1 testuser tstgrp     51 Dec 22 12:09 example1
drwx------. 2 nobody   nobody  16384 Dec 22 11:51 lost+found
-rwxr-xr-x. 1 testuser tstgrp   6986 Jan 31 13:44 test
-rw-r--r--. 1 testuser tstgrp 102400 Dec 22 12:00 test1
-rw-r--r--. 1 testuser tstgrp 102400 Dec 22 12:00 test10
Comment 7 Steve Dickson 2016-04-26 13:11:29 EDT

*** This bug has been marked as a duplicate of bug 1277801 ***

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