[Bug 1217885] New: dracut: the nfs module issues "rpc.statd: Running as root. chown /var/lib/nfs to choose different user"
https://bugzilla.suse.com/show_bug.cgi?id=1217885 Bug ID: 1217885 Summary: dracut: the nfs module issues "rpc.statd: Running as root. chown /var/lib/nfs to choose different user" Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: dracut-maintainers@suse.de Reporter: antonio.feijoo@suse.com QA Contact: qa-bugs@suse.de CC: nfbrown@suse.com Target Milestone: --- Found By: --- Blocker: --- CC: nfbrown@suse.com Flags: needinfo?(nfbrown@suse.com) Created attachment 871199 --> https://bugzilla.suse.com/attachment.cgi?id=871199&action=edit dracut patch While testing the dracut nfs module in Tumbleweed, I found this warning in the journal:
Dec 07 14:07:30 localhost systemd[1]: Starting dracut pre-udev hook... Dec 07 14:07:30 localhost kernel: RPC: Registered named UNIX socket transport m> Dec 07 14:07:30 localhost kernel: RPC: Registered udp transport module. Dec 07 14:07:30 localhost kernel: RPC: Registered tcp transport module. Dec 07 14:07:30 localhost kernel: RPC: Registered tcp-with-tls transport module. Dec 07 14:07:30 localhost kernel: RPC: Registered tcp NFSv4.1 backchannel trans> Dec 07 14:07:30 localhost rpc.statd[363]: Version 2.6.3 starting Dec 07 14:07:30 localhost rpc.statd[363]: Initializing NSM state ---> Dec 07 14:07:30 localhost rpc.statd[363]: Running as root. chown /var/lib/nfs to choose different user Dec 07 14:07:30 localhost rpc.idmapd[477]: Setting log level to 0 Dec 07 14:07:30 localhost rpc.idmapd[477]: libnfsidmap: requested translation method, 'nsswitch', is not available Dec 07 14:07:30 localhost systemd[1]: Finished dracut pre-udev hook.
I never saw this in SLE, but then I noticed that nfs-utils adds the statd user via sysusers.d configuration since version 2.5.1:
$ rpm -qf /usr/lib/sysusers.d/statd-user.conf nfs-client-2.6.3-41.1.x86_64 $ cat /usr/lib/sysusers.d/statd-user.conf # Type Name ID GECOS [HOME] Shell u statd - "NFS statd daemon" /var/lib/nfs -
Also, the nfs-utils.spec file defines:
# lib/nfs must be root-owned. # sm and sm.back and contents should be statd:statd, # but only chown if the dirs are currently root-owned. # This is needed for some upgraded, but chown is best avoided # when not necessary ... %{_sysusersdir}/statd-user.conf %dir %{_localstatedir}/lib/nfs %dir %{_localstatedir}/lib/nfs/rpc_pipefs %dir %{_localstatedir}/lib/nfs/v4recovery %attr(0700,statd,statd) %dir %{_localstatedir}/lib/nfs/sm %attr(0700,statd,statd) %dir %{_localstatedir}/lib/nfs/sm.bak %ghost %{_localstatedir}/lib/nfs/state
Neil, I can't find this in nfs-utils upstream, is this SUSE-specific? how bad is this warning? should we add a custom patch (maybe similar to the one attached) to the dracut nfs module to avoid it? -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1217885 https://bugzilla.suse.com/show_bug.cgi?id=1217885#c1 --- Comment #1 from Neil Brown <nfbrown@suse.com> --- Why are we even running rpc.statd from the initrd - that doesn't make a lot of sense. What filesystem is being mounted? Presumably a root filesystem? Is this root filesystem shared with other clients? If so do all the clients treat as read-only? If the filesystem mounted is never shared, or if it is only accessed read-only. then we don't need NFS locking, and so don't need rpc.statd. Possibly the problem is that NFS is starting rpc.statd when it doesn't need to. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1217885 https://bugzilla.suse.com/show_bug.cgi?id=1217885#c2 Antonio Feijoo <antonio.feijoo@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(nfbrown@suse.com) |needinfo?(thomas.blume@suse | |.com) CC| |thomas.blume@suse.com --- Comment #2 from Antonio Feijoo <antonio.feijoo@suse.com> --- (In reply to Neil Brown from comment #1)
Why are we even running rpc.statd from the initrd - that doesn't make a lot of sense.
Maybe this code is outdated, it was introduced in 2009 (https://github.com/dracutdevs/dracut/commit/f6f74096f6fa2bac0e841f21134dba00...), at least it was added with the following comment: ``` # Start rpc.statd as mount won't let us use locks on a NFSv4 # filesystem without talking to it. NFSv4 does locks internally, # rpc.lockd isn't needed ```
What filesystem is being mounted? Presumably a root filesystem?
Yes.
Is this root filesystem shared with other clients? If so do all the clients treat as read-only?
I don't know the answer to this question. Thomas, have you ever seen the dracut nfs module on a real customer setup?
If the filesystem mounted is never shared, or if it is only accessed read-only. then we don't need NFS locking, and so don't need rpc.statd.
Possibly the problem is that NFS is starting rpc.statd when it doesn't need to.
Thanks for this background. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1217885 https://bugzilla.suse.com/show_bug.cgi?id=1217885#c3 Thomas Blume <thomas.blume@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(thomas.blume@suse | |.com) | --- Comment #3 from Thomas Blume <thomas.blume@suse.com> --- (In reply to Antonio Feijoo from comment #2)
Is this root filesystem shared with other clients? If so do all the clients treat as read-only?
I don't know the answer to this question. Thomas, have you ever seen the dracut nfs module on a real customer setup?
Yeah, I remember some setups on diskless clients. But Neil is right, a shared rw nfsroot doesn't make any sense as clients would overwrite each other. AFAICR all of these shared nfsroot setups were ro. So, I guess we can live without NFS locking for nfsroot in the initrd. Still, I would put a kind of warning there that shared nfsroot in rw mode is not supported. Just in case someone finds a usecase one day. -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠suse.com