I've been trying to debug a problem where on a fresh F21 install, I can't do an NFS3 mount. Mounting tries to start rpc.statd (rpc-statd.service) which requires rpcbind.target, and rpcbind.target actually starts fine. But rpcbind is socket activated and nothing at all that I can see actually starts rpcbind.socket. If I start rpcbind.socket manually, everything works fine. rpcbind-0.2.2-2.1.fc21.x86_64 nfs-utils-1.3.1-6.1.fc21.x86_64 systemd-216-20.fc21.x86_64
And, in case anyone else stumbles on this: systemctl enable rpcbind.socket systemctl start rpcbind.socket works around the problem well enough, though from what I gather this isn't supposed to be necessary.
I'm beginning to thinks this is a systemd issued. Ever since commit 061eaaeeb588122350fa3fc4d81ac814c59fbd84 Author: Tom Gundersen <teg> Date: Tue Nov 25 11:41:50 2014 -0500 rpcbind: add support for systemd socket activation There has been problems. I noticed today that if you reboot a machine and the first thing done is a 'rpcinfo -p'. The command hangs but rpcbind is started! The rpcinfo will time out complaining about not being able to talk to rpcbind. If another rpcinfo -p is done, it works as expected. So it appears to be a problem in the systemd activation code or the implementation of the systemd activation code. I'm assigning this to the systemd folks because I simply have no idea how to debug this
As far as I can tell, this problem has gone away. I removed the bits from my kickstart files which force-enabled rpcbind.socket and installed fresh F21 and F22 machines. Everything seems to be working as expected.
(In reply to Jason Tibbitts from comment #3) > As far as I can tell, this problem has gone away. > > I removed the bits from my kickstart files which force-enabled > rpcbind.socket and installed fresh F21 and F22 machines. Everything seems > to be working as expected. A patch went in for nfs-utils-1.3.2-9.fc22 and nfs-utils-1.3.1-6.4.fc21 that took care of this problem. *** This bug has been marked as a duplicate of bug 1178720 ***