Bug 1277801

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

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

(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?

*** Bug 1313721 has been marked as a duplicate of this bug. ***

(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.

(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.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..

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.

All "Red Hat Customer Portal" has been closed.

is this still a issue now ?

Yes, this is still an issue. Everything I said in comment #6 still applies.

But this is low priority for us, because we just use Puppet to stomp all of the systemd unit files that the nfs-utils package provides with our own versions that don't have the service coupling, and then implement resource dependency ordering using Puppet. And Puppet has vastly more powerful resource dependency ordering capabilities than systemd.

As some point, I may make the argument against using BindsTo to upstream. But that's an upstream issue, not a Red Hat issue, so I think this ticket is best left closed.