Steve, what do you think about this proposal?

steved, I think all of FESCo would like your input on this. So I've tagged this for FESCo's meeting but I'm not putting it on the agenda until next week. Could you give us some thoughts on whether you think this would be a good change by then?

+1 to getting Steve's input, but, I'm also in favor of removing the exception (and +1 to that if it comes to a vote today).

+1 to removing the exception, assuming nothing goes horrifically wrong, given nfs will activate it itself.

rpcbind is needed by both the NFS v3 server and the v3 client.

On the client side, the kernel will call up to rpcbind to get the local statd port.

When a client does a mount, it queries the rpcbind on the server for the NFS port and mountd's port.

So the question is will this type of network activity (remote and local) cause rpcbind to start before its needed? If the answer is yes, then good I will be more than willing to try.

But if the answer is no, its very probable all v3/v2 NFS mount will break.

steved: See https://fedoraproject.org/wiki/Features/PackagePresets and {{{/usr/lib/systemd/system-preset/90-default.preset}}}

I am pretty sure this should stay on. I wouldn't really consider portmap that much of a server. It's just part of the client in my eyes, and NFS mounts that just work is certainly a good thing. Note that portmap is socket-activated, hence doesn't even run unless you actually have an NFS mount.

That said, I don't have any stake in the game here, whatever FESCO decides...

Any news here? Has anyone tested?

OK, I made some tests:

=== Before any changes ===

== from the client side, nfs4 ==

systemctl status rpcbind.{socket,service,target} rpc-statd.service
shows that only rpcbind.socket is active

sudo mount -t nfs server.local:/mnt/shared /home2

works without any trouble. I was surprised to see that nfs4 has become the default.

== from the client side, nfs3 ==

After unmounting /home2, only rpcbind.socket is active.

sudo mount -t nfs server.local:/mnt/shared /home2 -o vers=3

Mounting works. rpcbind.{socket,service,target} rpc-statd.service are all active.

=== With changes ===

== without rpcbind.socket in sockets.target, nfs4 ==

Works as expected.

== without rpcbind.socket in sockets.target, nfs3 ==

I modified rpcbind.socket to contain [Install] RequiredBy=rpcbind.target, instead of [Install] WantedBy=sockets.target, and did systemctl reenable rpcbind.socket.

After reboot:

sudo mount -t nfs server.local:/mnt/shared /home2 -o vers=3
... there's a long timeout...
Job for rpc-statd.service failed. See 'systemctl status rpc-statd.service' and 'journalctl -xn' for details.

rpcbind.{socket,target,service} are active, rpc-statd.service is failed with error 'failed to create RPC listeners, exiting'.

systmectl status $(pgrep statd) shows that rpc.statd --no-notify is running as part of session-1.scope, as rpcuser user. rpc-statd.service cannot start because this one is already running.

Nevertheless, /home2 is mounted, and seems to work.

So there seems to be some confusion between what is started as a systemd unit, and what it started "manually" by mount.

$ rpm -q systemd nfs-utils util-linux
systemd-214-4.fc21.x86_64
nfs-utils-1.3.0-3.0.fc21.x86_64
util-linux-2.25-0.1.fc21.x86_64

rpcbind should not start by default. (+7,0,0)

This will need changing in systemd preset and perhaps a release note on what to do if you still need v3.

That's a surprising outcome. Maybe I should have been more explicit, like "works, but badly and slowly, starts daemons which will be killed when the user logs out, displays errors, takes a long time, and seems like a bad idea in general"... But sure, we can flip the default in presets and wait for the bugs to come in.

Unless I'm missing something here, this is just a bug in /usr/bin/start-statd:

{{{

!/bin/bash -p

nfsmount calls this script when mounting a filesystem with locking

enabled, but when statd does not seem to be running (based on

/var/run/rpc.statd.pid).

It should run statd with whatever flags are apropriate for this

site.

PATH="/sbin:/usr/sbin:/bin:/usr/bin"
if systemctl start nfs-lock.service
then :
else
exec rpc.statd --no-notify
fi
}}}

This should work, but from the discussion, it seems to be broken somehow.

Is there any action here? FESCo seems to have resolved this, but I don't see any tickets filed or anything else happening.

Thanks for following up; I have now reopened https://bugzilla.redhat.com/show_bug.cgi?id=1099595 as we should have done immediately.

I suppose that leaves us the possibly necessary release note (who will write it? How can we track it?) and comment:15, which should go to bugzilla instead.

This bug will also need to be fixed to make the preset removal take effect: https://bugzilla.redhat.com/show_bug.cgi?id=1087951

I also filed a bug for comment:15:

https://bugzilla.redhat.com/show_bug.cgi?id=1129425