On 06/18/2014 09:17 AM, Tobias Powalowski wrote:
After running this update - my nfs server won't run at all - I get this error:
systemctl status nfs-server ● nfs-server.service - NFS server and services Loaded: loaded (/usr/lib/systemd/system/nfs-server.service; enabled) Active: failed (Result: exit-code) since Fri 2014-06-20 16:07:08 EDT; 5s ago Process: 872 ExecStart=/usr/sbin/rpc.nfsd $RPCNFSDARGS (code=exited, status=1/FAILURE) Process: 868 ExecStartPre=/usr/sbin/exportfs -r (code=exited, status=0/SUCCESS) Main PID: 872 (code=exited, status=1/FAILURE)
..rpc.nfsd[872]: rpc.nfsd: writing fd to kernel failed: errno 11(...ed) ..rpc.nfsd[872]: rpc.nfsd: unable to set any sockets for nfsd ..fs-server.service: main process exited, code=exited,...URE ..Failed to start NFS server and services.
Help? I tried to downgrade nfs-utils but that did not put things back in a good state.
On 06/20/2014 04:16 PM, Genes Lists wrote: ...
..rpc.nfsd[872]: rpc.nfsd: writing fd to kernel failed: errno 11(...ed)
More strangeness - after a while I tried loading all the pieces by hand - and suprisingly that worked. Then after that, the systemd nfs-server service works if re-started ... specifically I did:
systemctl restart proc-fs-nfsd.mount
systemctl restart rpcbind systemctl restart nfs-mountd.service systemctl restart rpc-statd.service systemctl restart nfs-idmapd.service systemctl restart rpc-svcgssd.service systemctl restart rpc-statd-notify.service systemctl restart nfs-mountd systemctl restart rpc-gssd.service rpc-svcgssd.service
exportfs -r /usr/sbin/rpc.nfsd
systemctl restart rpcbind systemctl restart rpc-statd-notify.service systemctl status rpc-statd-notify.service
All worked fine. Then if I do systemctl restart nfs-server
there are no more errors.
I am stumped. Only thing I did not mention was I did reboot server after installing the new nfs-utils from testing (kernel 3.15.1). nfs-server did not start on boot - or by (re)starting nfs-server service after machine was up (and nfs-server service failed) during boot.
Perplexed - but sharing in case others see similar odd behaviour.
Gene
This is probably unlikely but I'll ask. Is it possible that something that nfs needed (but missing from systemd service file) had not actually come up yet but several minutes later it was up and then nfs was able to start?
Thought I'd ask.
gene/
Am Fri, 20 Jun 2014 16:48:21 -0400 schrieb Genes Lists lists@sapience.com:
This is probably unlikely but I'll ask. Is it possible that something that nfs needed (but missing from systemd service file) had not actually come up yet but several minutes later it was up and then nfs was able to start?
Thought I'd ask.
gene/
I'm also affected by this issue. This could be a missing dependency /mixed up order in the nfs startup.
-Andy
Am Sat, 21 Jun 2014 08:59:30 +0200 schrieb Andreas Radke andyrtr@archlinux.org:
Am Fri, 20 Jun 2014 16:48:21 -0400 schrieb Genes Lists lists@sapience.com:
This is probably unlikely but I'll ask. Is it possible that something that nfs needed (but missing from systemd service file) had not actually come up yet but several minutes later it was up and then nfs was able to start?
Thought I'd ask.
gene/
I'm also affected by this issue. This could be a missing dependency /mixed up order in the nfs startup.
-Andy
This can be fixed by explicitly enabling rpcbind.service on the server.
But this shouldn't be necessary because nfs-server.service has:
grep rpcbind /usr/lib/systemd/system/nfs-server.service Requires= network.target proc-fs-nfsd.mount rpcbind.target After= network.target proc-fs-nfsd.mount rpcbind.target nfs-mountd.service
So I assume some race condition or bug here though.
-Andy
Am Sun, 22 Jun 2014 09:49:29 +0200 schrieb Andreas Radke andyrtr@archlinux.org:
But this shouldn't be necessary because nfs-server.service has:
grep rpcbind /usr/lib/systemd/system/nfs-server.service Requires= network.target proc-fs-nfsd.mount After= network.target proc-fs-nfsd.mount rpcbind.target nfs-mountd.service
So I assume some race condition or bug here though.
-Andy
Replacing rpcbind.target with rpcbind.service does fix it here. Not sure if this is the proper solution. This should be decided upstream.
-Andy
Am 22.06.2014 09:57, schrieb Andreas Radke:
Am Sun, 22 Jun 2014 09:49:29 +0200 schrieb Andreas Radke andyrtr@archlinux.org:
But this shouldn't be necessary because nfs-server.service has:
grep rpcbind /usr/lib/systemd/system/nfs-server.service Requires= network.target proc-fs-nfsd.mount After= network.target proc-fs-nfsd.mount rpcbind.target nfs-mountd.service
So I assume some race condition or bug here though.
-Andy
Replacing rpcbind.target with rpcbind.service does fix it here. Not sure if this is the proper solution. This should be decided upstream.
-Andy
Fixed in rpcbind-0.2.1-4, which uses socket activation. greetings tpowa
More problems - could really use some help on this one.
Rebooted the server today after full update (testing) - now ALL nfs clients get Input/Output error on any symbolic link - regular files are fine.
Server/client both:
nfs-utils 1.3.0-2 rpcbind 0.2.1-5
On any client (this is an internal mirror of arch repo - so testing.db is a symbolic link to test.db.tar,gz)
# ls -l testing.db testing.db.tar.gz ls: cannot read symbolic link testing.db: Input/output error 0 lrwxrwxrwx 1 root root 17 Jun 28 14:12 testing.db 16 -rw-rw-r-- 1 root root 14204 Jun 28 14:12 testing.db.tar.gz
On server: ls -l testing.db testing.db.tar.gz lrwxrwxrwx 1 root root 17 Jun 28 14:12 testing.db -> testing.db.tar.gz -rw-rw-r-- 1 root root 14204 Jun 28 14:12 testing.db.tar.gz
One more piece of info:
If on the client - I create a new symbolic link - it is fine on both client and server.
On Client:
# ln -s testing.db.tar.gz JUNK # ls -l JUNK 0 lrwxrwxrwx 1 root root 17 Jun 28 20:24 JUNK -> testing.db.tar.gz
Same back on the NFS server ...
# ls -l JUNK testing.db lrwxrwxrwx 1 root root 17 Jun 28 20:24 JUNK -> testing.db.tar.gz lrwxrwxrwx 1 root root 17 Jun 28 14:12 testing.db -> testing.db.tar.gz
Very weird ...
Rebooted server a second time (prev clients were rebooted first) - and now all clients are happy.
Odd no?
arch-general@lists.archlinux.org