Bug 1277801 - nfs-idmapd.service contains bogus dependency on nfs-server.service
nfs-idmapd.service contains bogus dependency on nfs-server.service
Status: NEW
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: nfs-utils (Show other bugs)
7.1
Unspecified Unspecified
high Severity high
: rc
: ---
Assigned To: Steve Dickson
Yongcheng Yang
:
: 1313721 (view as bug list)
Depends On:
Blocks: 1298243 1420851
  Show dependency treegraph
 
Reported: 2015-11-04 00:48 EST by James Ralston
Modified: 2017-06-24 21:03 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
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 James Ralston 2015-11-04 00:48:13 EST
Description of problem:

The nfs-idmapd.service systemd unit file contains this line:

BindsTo=nfs-server.service

Not only does this means that starting idmapd will start the NFS server, but it means that stopping the NFS server will stop idmapd.

This effectively precludes running an NFSv4 client that is not also an NFSv4 server. But running an NFSv4 client that is not also an NFSv4 server is, in fact, an extremely common configuration. So this dependency is bogus.

To correct this, the BindsTo line should be removed from the nfs-idmapd.service systemd unit file.

I'm not sure why there's nfs-client.target instead of nfs-client.service (like nfs-server.service), but the nfs-client.target should contain Wants/After dependencies on nfs-idmapd.service, the same as nfs-server.service.

Version-Release number of selected component (if applicable):

1:nfs-utils-1.3.0-0.8.el7.x86_64

How reproducible:

Start nfs-idmapd.service, and watch as systemd attempts to start nfs-server.service.

Steps to Reproduce:
1. yum install nfs-utils
2. systemctl start nfs-idmapd.service
3. watch the sadness

Actual results:

The nfs-server service starts.

Expected results:

Only nfs-config.service should start when nfs-idmapd.service starts.

Additional info:

nfs-client.target and nfs-server.service both start daemons that are unnecessary (and unwanted) in a pure NFSv4 environment, which is why we're trying to manage the individual services we know we need (and ONLY those services), instead of using the meta-services/targets.
Comment 2 Ashima Rawat 2016-02-15 01:09:23 EST
Hi,

There has been a case 01580293 logged in for the same issue that starting nfs-idmapd.service starts nfs-server.service in RHEL 7.2.

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

o 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

So now customer wants to know if idmapd can be started without nfs-server as it is un-necessary to turn on an additional service when it is not needed.

Thanks
Ashima
Comment 3 Ashima Rawat 2016-02-21 01:09:21 EST
Hi,

The issue has been reported in RHEL 7.2. Could you please let me know if this issue would be handled as part of Bugzilla that was raised to address the issue in RHEL 7.1 or I need to file seperate bug.

Thanks
Ashima
Comment 4 Steve Dickson 2016-04-26 11:30:28 EDT
(In reply to James Ralston from comment #0)
> Description of problem:
> 
> The nfs-idmapd.service systemd unit file contains this line:
> 
> BindsTo=nfs-server.service
> 
> Not only does this means that starting idmapd will start the NFS server, but
> it means that stopping the NFS server will stop idmapd.
> 
> This effectively precludes running an NFSv4 client that is not also an NFSv4
> server. But running an NFSv4 client that is not also an NFSv4 server is, in
> fact, an extremely common configuration. So this dependency is bogus.
No. The NFS v4 client uses a kernel upcall to nfsidmap command
to do its id mapping. Only the nfs server uses rpc.idmapd.

> 
> To correct this, the BindsTo line should be removed from the
> nfs-idmapd.service systemd unit file.
Well I'll agree its a bit messy to have rpc-idmapd bring 
the NFS server up and down, but I don't why it would cause
any problem? What is the problem with this type of coupling?
Comment 5 Steve Dickson 2016-04-26 13:11:29 EDT
*** Bug 1313721 has been marked as a duplicate of this bug. ***
Comment 6 James Ralston 2016-04-26 16:00:38 EDT
(In reply to Steve Dickson from comment #4)
> No. The NFS v4 client uses a kernel upcall to nfsidmap command
> to do its id mapping. Only the nfs server uses rpc.idmapd.

Yes—I realized that after I filed this Bugzilla. My bad.

> Well I'll agree its a bit messy to have rpc-idmapd bring 
> the NFS server up and down, but I don't why it would cause
> any problem? What is the problem with this type of coupling?

Because it locks us into your definition of the service.

Here's an example. We run pure NFSv4 servers, using sec=krb5, integrated with sssd and Active Directory. We specifically and emphatically do NOT want any NFSv2/NFSv3 baggage (no rpcbind, lockd, statd, et. al.) running on our NFSv4 servers.

When we realized the default nfs-server.service unit file pulls in all of the v2/v3 service dependencies, our first reaction was to roll our own unit file, nfsv4-server.service, and use it instead.

But we couldn't, because nfsv4-server needs idmapd, and idmapd is coupled to nfs-server.service. Oops.

So to provide a pure NFSv4 server, we had to override nfs-server.service with our own version in /etc/systemd/system. And since we could not guarantee that future releases of nfs-utils wouldn't change the coupling of other services in a way that would break what we had done, for safety, we overrode most of the other nfs-utils unit files as well.

If you want to make the lives of novice sysadmins easier by providing meta-services like nfs-server.service that encapsulate the dependencies required to provide a particular service, then great. That's one of the powers that systemd gives you (over SysVInit), and it makes sense to use it.

But please, pretty please, DON'T tie the constituent services back into those meta-services. Because that precludes sysadmins from rolling their own meta-services that depend on those constituent services.
Comment 7 Steve Dickson 2016-04-27 14:24:30 EDT
(In reply to James Ralston from comment #6)
> (In reply to Steve Dickson from comment #4)
> > Well I'll agree its a bit messy to have rpc-idmapd bring 
> > the NFS server up and down, but I don't why it would cause
> > any problem? What is the problem with this type of coupling?
> 
> Because it locks us into your definition of the service.
> 
> Here's an example. We run pure NFSv4 servers, using sec=krb5, integrated
> with sssd and Active Directory. We specifically and emphatically do NOT want
> any NFSv2/NFSv3 baggage (no rpcbind, lockd, statd, et. al.) running on our
> NFSv4 servers.
Understood...

> 
> When we realized the default nfs-server.service unit file pulls in all of
> the v2/v3 service dependencies, our first reaction was to roll our own unit
> file, nfsv4-server.service, and use it instead.
> 
> But we couldn't, because nfsv4-server needs idmapd, and idmapd is coupled to
> nfs-server.service. Oops.
The reason being is rpc.idmapd is needed for a v4 server,
especially since you are using Kerberos. How are 
the "name@domain" strings going to get  mapped into uid/gids? 
 
> 
> So to provide a pure NFSv4 server, we had to override nfs-server.service
> with our own version in /etc/systemd/system. And since we could not
> guarantee that future releases of nfs-utils wouldn't change the coupling of
> other services in a way that would break what we had done, for safety, we
> overrode most of the other nfs-utils unit files as well.
> 
> If you want to make the lives of novice sysadmins easier by providing
> meta-services like nfs-server.service that encapsulate the dependencies
> required to provide a particular service, then great. That's one of the
> powers that systemd gives you (over SysVInit), and it makes sense to use it.
> 
> But please, pretty please, DON'T tie the constituent services back into
> those meta-services. Because that precludes sysadmins from rolling their own
> meta-services that depend on those constituent services.
I'm more than willing to work with you and I'm very supportive
of people trying doing a v4 only server... 

So lets do this... Let's go upstream with this... since I need
to change them in upstream and then backport the changes 
to RHEL7... That's just how it works... 

So please send some mail to linux-nfs@vger.kernel.org describing
what you are trying to do... If you are familiar with how to
send a patch... go ahead send a patch of what you want to do.

I'll chime in, and we will figure this out... I'm sure
other people are trying do this... 

Again, I'm all for making v4 only servers work... we just
have to go through upstream first..
Comment 8 arthurguru 2016-12-10 21:09:24 EST
Noticed on RH7.3 that nfs-idmap.service symlinks to nfs-idmapd.service (or is it the other way around).

On my NFSv4 client (RH7.3), nfs-idmapd fails to start at boot because it depends on nfs-server, however it does start by hand. I ended up starting it from a privately defined service at boot time.

Seems to be some bad karma of late going into the NFSv4 upstream with some really obvious bugs being let loose.

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