Systemd programming, 30 months later

Posted Oct 10, 2016 17:39 UTC (Mon) by flussence (guest, #85566)
In reply to: Systemd programming, 30 months later by nybble41
Parent article: Systemd programming, 30 months later

> Is it possible to (easily) configure NFS to perform the same task?
Possible? In theory.

Easy? I've just wasted a weekend navigating a maze of outdated docs and 404-ing websites trying to get NFS to do anything and *once again* gave up in frustration. That includes reading nfsd(8), nfsd(7), nfs(5), and the linux-nfs/README file - which makes it sound like this is all abandonware.

Right out of the starting gate, trying the simplest possible thing that should work according to its own documentation, NFS fails to be sane: I run "rpc.nfsd -d -N 3". And then it hangs in D state for two minutes, not responding to Ctrl+C or Ctrl+\. No errors on the terminal, no errors in dmesg. pstree and ss show that it's running afterwards but drops all incoming connections.

What a horrid practical joke. I'll stick with running sshfs as root+allow_other.

Systemd programming, 30 months later

Posted Oct 11, 2016 9:26 UTC (Tue) by neilbrown (subscriber, #359) [Link] (2 responses)

> And then it hangs in D state for two minutes, not responding to Ctrl+C or Ctrl+\.

You didn't have rpcbind running. Had you been using the upstream systemd unit files....

(Still, it shouldn't hang. I've reported this and proposed a solution, but no forward progress yet).

Systemd programming, 30 months later

Posted Oct 11, 2016 20:40 UTC (Tue) by flussence (guest, #85566) [Link] (1 responses)

Looks like I was holding the manual upside down all along. I had the impression all the RPC stuff was unnecessary with NFSv4.

But thanks, that gave me enough of a push in the right direction to finally get it working. For the benefit of others, here's everything I ended up doing:

Poke a hole in the firewall for UDP/TCP 2049.

These two RPC things were the magic pixie dust I was missing (excerpt from pstree -a):


├─runsv rpcbind
│   └─rpcbind -f
└─runsv rpc.mountd
    └─rpc.mountd -N 3 -F

Start the in-kernel nfsd *after* those, using rpc.nfsd -H ${bind_addr} -N 3 $(nproc). This will return immediately provided rpcbind is running, and afterwards /proc/fs/nfsd/ should have become mounted. Stopping the server is done with rpc.nfsd 0 if needed.
Running rpcinfo now should show the portmapper, nfs and mountd services running.
Edit /etc/exports and run exportfs -a. Take note of the other comments up-thread: a manual bind mount and fsid=0 setup is unnecessary. no_subtree_check isn't needed either, but I put it in to avoid loud warning messages.

That, surprisingly, is all it needed. autofs's NFS autodetection depends on the showmount command which doesn't speak NFSv4, so I gave up on that route.

Systemd programming, 30 months later

Posted Oct 11, 2016 21:55 UTC (Tue) by neilbrown (subscriber, #359) [Link]

> I had the impression all the RPC stuff was unnecessary with NFSv4.

rpcbind isn't technically necessary, but there is kernel bug since v4.3 (commit 4b0ab51db32) which introduces a long timeout when starting nfsd without rpcbind running, even if you only request NFSv4. I hadn't properly noticed that you were requesting v4-only - sorry. rpc.nfsd tries to register with rpcbind even for v4, but if it fails (which currently means if it times out) it proceeds anyway.

rpc.mountd is needed, not for the RPC services it provides but for other lookup services it provides directly to the kernel. If you ask rpc.mountd to not support v2 or v3 (-N 2 -N 3) then it won't register with rpcbind at all and wont serve any rpc requests.