Why does nfsv4-service.service start rpcbind (pure NFSv4.2)

graysky · 2023-02-05 13:14:58

In researching a pure NFSV4 setup, it seems that rpcbind is not needed, yet the provided starting /usr/lib/systemd/system/nfsv4-server.service pulls some dependency that starts rpcbind. Am I missing something or is this an upstream bug? Is it an Arch packaging bug?

Thanks all.

Related old thread: https://bbs.archlinux.org/viewtopic.php?id=193629
Related bug report: https://bugs.archlinux.org/task/76453

1. Set this in /etc/nfs.conf (vers3=n under the [nfsd] section)
2. systemctl start nfsv4-server

Result:

% systemctl is-active rpcbind
active

% ps aux | grep rpc
root     1464741  0.0  0.0   4728  2980 ?        Ss   08:07   0:00 /usr/sbin/rpc.idmapd
rpc      1464745  0.0  0.0   7824  3936 ?        Ss   08:07   0:00 /usr/bin/rpcbind -w -f
rpcuser  1464749  0.0  0.0   4360   296 ?        Ss   08:07   0:00 /usr/sbin/rpc.statd
root     1464750  0.0  0.0   4852   384 ?        Ss   08:07   0:00 /usr/sbin/rpc.mountd
root     3198359  0.0  0.0      0     0 ?        I<   Feb01   0:00 [rpciod]

For the record, my /etc/exports:

/srv/nfs          10.9.8.0/24(ro,no_subtree_check,async,no_wdelay,fsid=0)
/srv/nfs/share1  10.9.8.0/24(rw,no_subtree_check,async,no_wdelay,no_root_squash)
/srv/nfs/share2  10.9.8.0/24(rw,no_subtree_check,async,no_wdelay,no_root_squash)

seth · 2023-02-05 13:59:32

Sure the socket isn't simply enabled?

find /etc/systemd -type l -exec test -f {} \; -print | awk -F'/' '{ printf ("%-40s | %s\n", $(NF-0), $(NF-1)) }' | sort -f

graysky · 2023-02-05 14:03:58

I do not see it in the output:

% find /etc/systemd -type l -exec test -f {} \; -print | awk -F'/' '{ printf ("%-40s | %s\n", $(NF-0), $(NF-1)) }' | sort -f          
cups.socket                              | sockets.target.wants
dbus-org.freedesktop.network1.service    | system
dbus-org.freedesktop.resolve1.service    | system
default.target                           | system
display-manager.service                  | system
fstrim.timer                             | timers.target.wants
gcr-ssh-agent.socket                     | sockets.target.wants
getty@tty1.service                       | getty.target.wants
gnome-keyring-daemon.socket              | sockets.target.wants
p11-kit-server.socket                    | sockets.target.wants
pulseaudio.socket                        | sockets.target.wants
remote-fs.target                         | multi-user.target.wants
rngd.service                             | sysinit.target.wants
systemd-networkd-wait-online.service     | network-online.target.wants
systemd-networkd.service                 | multi-user.target.wants
systemd-networkd.socket                  | sockets.target.wants
systemd-resolved.service                 | multi-user.target.wants
systemd-timesyncd.service                | sysinit.target.wants

But:

% systemctl list-sockets |grep rpc 
/run/rpcbind.sock            rpcbind.socket                  rpcbind.service
0.0.0.0:111                  rpcbind.socket                  rpcbind.service
0.0.0.0:111                  rpcbind.socket                  rpcbind.service
[::]:111                     rpcbind.socket                  rpcbind.service
[::]:111                     rpcbind.socket                  rpcbind.service

And:

% systemctl list-units |grep rpc
  var-lib-nfs-rpc_pipefs.mount                                                                          loaded active mounted   RPC Pipe File System
  rpc-statd-notify.service                                                                              loaded active exited    Notify NFS peers of a restart
  rpc-statd.service                                                                                     loaded active running   NFS status monitor for NFSv2/3 locking.
  rpcbind.service                                                                                       loaded active running   RPC Bind
  rpcbind.socket                                                                                        loaded active running   RPCbind Server Activation Socket
  rpc_pipefs.target                                                                                     loaded active active    rpc_pipefs.target
  rpcbind.target                                                                                        loaded active active    RPC Port Mapper

Last edited by graysky (2023-02-05 14:07:50)

seth · 2023-02-05 14:15:09

systemctl list-dependencies nfsv4-server.service

doesn't suggest a dependency here.
Is nfs-server also active?

Edit: as aa quick mitigation you could mask socket and service or simply block port 111

Last edited by seth (2023-02-05 14:15:51)

graysky · 2023-02-05 15:47:31

I don't see rpc* in the output, but nfs-server is also active interestingly and for reasons I cannot explain.

% systemctl list-dependencies nfsv4-server.service
nfsv4-server.service
○ ├─auth-rpcgss-module.service
● ├─nfs-idmapd.service
● ├─nfsdcld.service
● ├─nfsv4-exportd.service
● ├─proc-fs-nfsd.mount
● ├─system.slice
● ├─network-online.target
● │ └─systemd-networkd-wait-online.service
● └─network.target

% systemctl is-active rpcbind                   
active

% systemctl is-active nfs-server
active

% systemctl is-active nfsv4-server       
active

Circling back to my original question: is this an upstream bug or an Arch packaging bug or is it the expected behavior?

EDIT: if I build nfs-utils pulling rpcbind out of the depends array, it behaves as I expect it to behave....

Last edited by graysky (2023-02-05 15:53:17)

seth · 2023-02-05 16:08:57

nfs-server "Wants" rpcbind, so if it's there it'll activate it and rpcbind is a reasonable dependency for NFSv3, so it gets installed.
(I'm not sure whether you can make any use out of NFSv3 w/o it)

You can make a case that rpcbind should™ be an optional dependency, as it's only required for part of the packages functionality (NFSv3), but neither it being installed nor nfs-server activating it is a bug per se.

The bug here is that for whatever reason nfs-server is active and as long as we don't know why that is, we can't say where the bug is.
Does it get activated w/ nfsv4-server and can you stop it (and rpcbind) w/o harming the latter?

graysky · 2023-02-05 16:17:06

1. I can stop nfs-server while nfsv4-server is running but that breaks the exports.
2. If I build nfs-server with rpcbind as an optional dependency, I get the expected behavior (ie no rpcbind running since the package is not installed).

The FS I linked above requesting this optdepends status for rpcbind was closed stating we just package what upstream recommends. They do in fact show it as a requirement. Is the conclusion of this that the bug lies with that upstream recommendation?

Last edited by graysky (2023-02-05 16:19:38)

just4arch · 2023-02-05 16:30:27

For what it's worth, I have nfsv4-server.service enabled without nfs-server.service or rpcbind.* running.
Did you restart nfsv4-server.service after stopping/disabling nfs-server.service?

I just have these services running for NFSv4:

nfsv4-exportd.service
nfsdcld.service

I masked

nfs-idmapd.service
gssproxy.service

because I don't need them.

seth · 2023-02-05 16:40:46

% grep -r nfs-server /usr/lib/systemd/system
/usr/lib/systemd/system/rpc-statd-notify.service:After=nfs-server.service
/usr/lib/systemd/system/nfs-idmapd.service:BindsTo=nfs-server.service
/usr/lib/systemd/system/nfs-mountd.service:BindsTo=nfs-server.service

% systemctl list-dependencies nfsv4-server
nfsv4-server.service
○ ├─auth-rpcgss-module.service
○ ├─nfs-idmapd.service
○ ├─nfsdcld.service
○ ├─nfsv4-exportd.service
● ├─proc-fs-nfsd.mount
● ├─system.slice
● ├─network-online.target
● └─network.target

% systemctl list-dependencies nfs-server
nfs-server.service
○ ├─auth-rpcgss-module.service
○ ├─nfs-idmapd.service
○ ├─nfs-mountd.service
○ ├─nfsdcld.service
● ├─proc-fs-nfsd.mount
○ ├─rpc-statd-notify.service
○ ├─rpc-statd.service
○ ├─rpcbind.socket
● ├─system.slice
● ├─network-online.target
● └─network.target

nvsv4-server depends on nfs-idmapd.service and that binds to nfs-server.service and that depends on rpcbind.
The upstream "bug" is in their systemd service configuration that does not allow nfsv4-server to be started w/o ultimately drawing in rpcbind.service

Also https://wiki.archlinux.org/title/NFS#En … _idmapping
So you'd enable that and edit the nvsv4-server.service to not depend on nfs-idmapd.service and that should™ prevent the invocation of nfs-server and by inference rpcbind.

Edit: as meanwhile proven by just4arch

Last edited by seth (2023-02-05 16:41:34)

graysky · 2023-02-05 20:22:14

Thanks guys. It is probably more simplistic to just mask rpcbind.service and rpcbind.socket vs maintaining a custom package. That seems to be giving me the desired result. Might need to update the wiki to help others. For the record, I also masked nfs-idmapd gssproxy and nfs-server and everything seems to be workin g fine.

Last edited by graysky (2023-02-06 11:02:37)

Arch Linux

#1 2023-02-05 13:14:58

Why does nfsv4-service.service start rpcbind (pure NFSv4.2)

#2 2023-02-05 13:59:32

Re: Why does nfsv4-service.service start rpcbind (pure NFSv4.2)

#3 2023-02-05 14:03:58

Re: Why does nfsv4-service.service start rpcbind (pure NFSv4.2)

#4 2023-02-05 14:15:09

Re: Why does nfsv4-service.service start rpcbind (pure NFSv4.2)

#5 2023-02-05 15:47:31

Re: Why does nfsv4-service.service start rpcbind (pure NFSv4.2)

#6 2023-02-05 16:08:57

Re: Why does nfsv4-service.service start rpcbind (pure NFSv4.2)

#7 2023-02-05 16:17:06

Re: Why does nfsv4-service.service start rpcbind (pure NFSv4.2)

#8 2023-02-05 16:30:27

Re: Why does nfsv4-service.service start rpcbind (pure NFSv4.2)

#9 2023-02-05 16:40:46

Re: Why does nfsv4-service.service start rpcbind (pure NFSv4.2)

#10 2023-02-05 20:22:14

Re: Why does nfsv4-service.service start rpcbind (pure NFSv4.2)

Board footer