Mark Selby
2015-Aug-31 01:39 UTC
[CentOS] CentOS 7.1 NFS Client Issues - rpc.statd / rpcbind
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 at 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
Rob Kampen
2015-Aug-31 02:45 UTC
[CentOS] CentOS 7.1 NFS Client Issues - rpc.statd / rpcbind
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 at 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 at centos.org > https://lists.centos.org/mailman/listinfo/centos
Mark Selby
2015-Aug-31 03:48 UTC
[CentOS] CentOS 7.1 NFS Client Issues - rpc.statd / rpcbind
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 at 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 at 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 at centos.org >> https://lists.centos.org/mailman/listinfo/centos > > _______________________________________________ > CentOS mailing list > CentOS at centos.org > https://lists.centos.org/mailman/listinfo/centos