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.