I have seen some talk about this but have not seen any answers. I know this is a problem on CentOS 7.1 and I also think it is a problem on CentOS 7.0.
Basically if I have an NFS client only config - meaning that the nfs-server.service is not enabled then I have to wait 60 seconds after boot for the 1st NFSV3 mount to succeed.
What I can surmise is the following. I attempt to perform a NFS mount a newly booted machine and systemd via listening sockets
(1) starts rpc.statd (fails) (2) starts rpcbind (3) rpc.statd timesout after 60 seconds and then starts sucessfully (3) performs the nfs mount
I see that rpc.statd is attempted to start at the time that I perform the mount request - it just takes 60 seconds to start. I think this is because it tries to start before rpcbind is really stated and then waits a full 60 seconds before retying. It then succeeds because rpcbind is really started
I can fix the delay by running 'systemctl start rpcbind' after I reboot which causes rpcbind to start and not just be socket activated.
I see in the systemd manifest for rpc-statd that it does require rpcbind but I think systemd is trying to start rpc.statd before rpcbind which makes sense that this would not work.
If I enable nfs-server.service then rpcbind does really get started but I loathe to start this on all clients
Anyone have any ideas how to get rpcbind started before rpc.statd in a NFS client only config
root /root 103# systemd-analyze blame 1min 87ms rpc-statd.service
root@ls2 /root 79# systemctl list-units | grep rpc rpcbind.socket loaded active listening RPCbind Server Activation Socket
Aug 30 18:17:14 ls2.tokenrain.name systemd: Starting NFS status monitor for NFSv2/3 locking.... Aug 30 18:17:14 ls2.tokenrain.name rpc.statd[1938]: Version 1.3.0 starting Aug 30 18:17:14 ls2.tokenrain.name rpc.statd[1938]: Flags: TI-RPC Aug 30 18:17:14 ls2.tokenrain.name systemd: Starting RPC bind service... Aug 30 18:17:14 ls2.tokenrain.name systemd: Started RPC bind service. Aug 30 18:18:14 ls2.tokenrain.name systemd: Started NFS status monitor for NFSv2/3 locking..
USER PID PPID %CPU %MEM VSZ RSS TT STAT START TIME COMMAND root 1935 1924 0.0 0.0 115212 1436 ? S 18:17 00:00:00 /bin/bash -p /usr/sbin/start-statd root 1936 1935 0.0 0.0 132520 1196 ? S 18:17 00:00:00 systemctl start rpc-statd.service root 1937 1 0.0 0.0 44288 1676 ? Ss 18:17 00:00:00 /usr/sbin/rpc.statd --no-notify root 1938 1937 0.0 0.0 44484 1340 ? Ss 18:17 00:00:00 /usr/sbin/rpc.statd --no-notify
USER PID PPID %CPU %MEM VSZ RSS TT STAT START TIME COMMAND rpcuser 1938 1 0.0 0.0 44484 1600 ? Ss 18:17 00:00:00 /usr/sbin/rpc.statd --no-notify
On 08/31/2015 01:39 PM, Mark Selby wrote:
I have seen some talk about this but have not seen any answers. I know this is a problem on CentOS 7.1 and I also think it is a problem on CentOS 7.0.
Basically if I have an NFS client only config - meaning that the nfs-server.service is not enabled then I have to wait 60 seconds after boot for the 1st NFSV3 mount to succeed.
What I can surmise is the following. I attempt to perform a NFS mount a newly booted machine and systemd via listening sockets
(1) starts rpc.statd (fails) (2) starts rpcbind (3) rpc.statd timesout after 60 seconds and then starts sucessfully (3) performs the nfs mount
I see that rpc.statd is attempted to start at the time that I perform the mount request - it just takes 60 seconds to start. I think this is because it tries to start before rpcbind is really stated and then waits a full 60 seconds before retying. It then succeeds because rpcbind is really started
why doesn't rpc.statd have rpcbind as a pre-requisite - i.e. must have rpcbind up and running b4 rpc.statd is allowed to start - surely the all singing dancing wonder systemd has such capability
I can fix the delay by running 'systemctl start rpcbind' after I reboot which causes rpcbind to start and not just be socket activated.
I see in the systemd manifest for rpc-statd that it does require rpcbind but I think systemd is trying to start rpc.statd before rpcbind which makes sense that this would not work.
If I enable nfs-server.service then rpcbind does really get started but I loathe to start this on all clients
Anyone have any ideas how to get rpcbind started before rpc.statd in a NFS client only config
root /root 103# systemd-analyze blame 1min 87ms rpc-statd.service
root@ls2 /root 79# systemctl list-units | grep rpc rpcbind.socket loaded active listening RPCbind Server Activation Socket
Aug 30 18:17:14 ls2.tokenrain.name systemd: Starting NFS status monitor for NFSv2/3 locking.... Aug 30 18:17:14 ls2.tokenrain.name rpc.statd[1938]: Version 1.3.0 starting Aug 30 18:17:14 ls2.tokenrain.name rpc.statd[1938]: Flags: TI-RPC Aug 30 18:17:14 ls2.tokenrain.name systemd: Starting RPC bind service... Aug 30 18:17:14 ls2.tokenrain.name systemd: Started RPC bind service. Aug 30 18:18:14 ls2.tokenrain.name systemd: Started NFS status monitor for NFSv2/3 locking..
USER PID PPID %CPU %MEM VSZ RSS TT STAT START TIME COMMAND root 1935 1924 0.0 0.0 115212 1436 ? S 18:17 00:00:00 /bin/bash -p /usr/sbin/start-statd root 1936 1935 0.0 0.0 132520 1196 ? S 18:17 00:00:00 systemctl start rpc-statd.service root 1937 1 0.0 0.0 44288 1676 ? Ss 18:17 00:00:00 /usr/sbin/rpc.statd --no-notify root 1938 1937 0.0 0.0 44484 1340 ? Ss 18:17 00:00:00 /usr/sbin/rpc.statd --no-notify
USER PID PPID %CPU %MEM VSZ RSS TT STAT START TIME COMMAND rpcuser 1938 1 0.0 0.0 44484 1600 ? Ss 18:17 00:00:00 /usr/sbin/rpc.statd --no-notify
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
That is the thing - rpc.statd does have rpcbind a pre-req. It looks like systemd is not handling this correctly. Just wondering if anyone knows a good way to fix.
root@ls2 /usr/lib/systemd/system 110# grep Requires rpc-statd.service Requires=nss-lookup.target rpcbind.target
On 8/30/15 7:45 PM, Rob Kampen wrote:
On 08/31/2015 01:39 PM, Mark Selby wrote:
I have seen some talk about this but have not seen any answers. I know this is a problem on CentOS 7.1 and I also think it is a problem on CentOS 7.0.
Basically if I have an NFS client only config - meaning that the nfs-server.service is not enabled then I have to wait 60 seconds after boot for the 1st NFSV3 mount to succeed.
What I can surmise is the following. I attempt to perform a NFS mount a newly booted machine and systemd via listening sockets
(1) starts rpc.statd (fails) (2) starts rpcbind (3) rpc.statd timesout after 60 seconds and then starts sucessfully (3) performs the nfs mount
I see that rpc.statd is attempted to start at the time that I perform the mount request - it just takes 60 seconds to start. I think this is because it tries to start before rpcbind is really stated and then waits a full 60 seconds before retying. It then succeeds because rpcbind is really started
why doesn't rpc.statd have rpcbind as a pre-requisite - i.e. must have rpcbind up and running b4 rpc.statd is allowed to start - surely the all singing dancing wonder systemd has such capability
I can fix the delay by running 'systemctl start rpcbind' after I reboot which causes rpcbind to start and not just be socket activated.
I see in the systemd manifest for rpc-statd that it does require rpcbind but I think systemd is trying to start rpc.statd before rpcbind which makes sense that this would not work.
If I enable nfs-server.service then rpcbind does really get started but I loathe to start this on all clients
Anyone have any ideas how to get rpcbind started before rpc.statd in a NFS client only config
root /root 103# systemd-analyze blame 1min 87ms rpc-statd.service
root@ls2 /root 79# systemctl list-units | grep rpc rpcbind.socket loaded active listening RPCbind Server Activation Socket
Aug 30 18:17:14 ls2.tokenrain.name systemd: Starting NFS status monitor for NFSv2/3 locking.... Aug 30 18:17:14 ls2.tokenrain.name rpc.statd[1938]: Version 1.3.0 starting Aug 30 18:17:14 ls2.tokenrain.name rpc.statd[1938]: Flags: TI-RPC Aug 30 18:17:14 ls2.tokenrain.name systemd: Starting RPC bind service... Aug 30 18:17:14 ls2.tokenrain.name systemd: Started RPC bind service. Aug 30 18:18:14 ls2.tokenrain.name systemd: Started NFS status monitor for NFSv2/3 locking..
USER PID PPID %CPU %MEM VSZ RSS TT STAT START TIME COMMAND root 1935 1924 0.0 0.0 115212 1436 ? S 18:17 00:00:00 /bin/bash -p /usr/sbin/start-statd root 1936 1935 0.0 0.0 132520 1196 ? S 18:17 00:00:00 systemctl start rpc-statd.service root 1937 1 0.0 0.0 44288 1676 ? Ss 18:17 00:00:00 /usr/sbin/rpc.statd --no-notify root 1938 1937 0.0 0.0 44484 1340 ? Ss 18:17 00:00:00 /usr/sbin/rpc.statd --no-notify
USER PID PPID %CPU %MEM VSZ RSS TT STAT START TIME COMMAND rpcuser 1938 1 0.0 0.0 44484 1600 ? Ss 18:17 00:00:00 /usr/sbin/rpc.statd --no-notify
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On 08/31/2015 05:48 AM, Mark Selby wrote:
That is the thing - rpc.statd does have rpcbind a pre-req. It looks like systemd is not handling this correctly. Just wondering if anyone knows a good way to fix.
root@ls2 /usr/lib/systemd/system 110# grep Requires rpc-statd.service Requires=nss-lookup.target rpcbind.target
This is a bug in the NFS service configuration files. You need to copy rpc-statd.service over to /etc/systemd/system and change the "rpcbind.target" to "rpcbind.service". Don't forget the "systemctl daemon-reload" afterwards if you don't reboot. See this bug for details: https://bugzilla.redhat.com/show_bug.cgi?id=1171603
Regards, Dennis