Re: Sid: NFS after upgrade
* Grzesiek Sójka [2018-10-28 11:27 +]: > Hi there, > > I just upgraded Sid and now I get the following during boot: > > [] Configuring network interfaces.../etc/init.d/rpcbind: 42: > /etc/init.d/rpcbind: stat: not found > /run/rpcbind not owned by root failed! > Starting NFS common utilities: statd https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911510 Elimar -- Numeric stability is probably not all that important when you're guessing;-)
Re: Sid: NFS after upgrade [solved] please fix /etc/init.d/rpcbind
On 2018-10-28 16:58 +, Grzesiek Sójka wrote: > On 10/28/18 2:10 PM, Sven Joachim wrote: >> Wouldn't it be better to fix the init system that sets such a bad >> default PATH? Whatever init system that may be - sysv-rc's >> /etc/init.d/rc script sets PATH=/sbin:/usr/sbin:/bin:/usr/bin, so this >> should not happen with sysvinit + sysv-rc. > > Please, keep in mind that /etc/init.d/rpcbind may also be invoked by > /etc/network/if-up.d/mountnfs (after bringing up interfaces): > > # grep PATH /etc/network/if-up.d/mountnfs > PATH=/sbin:/bin I see. This could be fixed in ifupdown by not setting PATH in its init scripts or by setting PATH in the rpcbind init script. Overall PATH handling in init scripts is a total mess and needs to be cleaned up. These days /usr is supposed to be mounted by the initramfs if it's on a different filesystem than /, so init scripts can rely on it being present. Please file a bug - most maintainers use systemd these days where those problems do not exist, so they won't notice them. Cheers, Sven
Re: Sid: NFS after upgrade [solved] please fix /etc/init.d/rpcbind
On 10/28/18 2:10 PM, Sven Joachim wrote: Wouldn't it be better to fix the init system that sets such a bad default PATH? Whatever init system that may be - sysv-rc's /etc/init.d/rc script sets PATH=/sbin:/usr/sbin:/bin:/usr/bin, so this should not happen with sysvinit + sysv-rc. Please, keep in mind that /etc/init.d/rpcbind may also be invoked by /etc/network/if-up.d/mountnfs (after bringing up interfaces): # grep PATH /etc/network/if-up.d/mountnfs PATH=/sbin:/bin What init system do you use? # apt --installed list | grep sys | cut -f 1 -d ' ' busybox-syslogd/unstable,now init-system-helpers/unstable,now libboost-filesystem1.62.0/unstable,now libboost-system1.62.0/unstable,now libsystemd0/unstable,now sysv-rc/unstable,now sysvinit-core/unstable,now sysvinit-utils/unstable,now -- Pozdrawiam Grzesiek Wysłane z kompa wolnego od wirusów Billa Gatesa.
Re: Sid: NFS after upgrade [solved] please fix /etc/init.d/rpcbind
On 2018-10-28 14:47 +, Grzesiek Sójka wrote: > On 10/28/18 11:27 AM, Grzesiek Sójka wrote: >> Hi there, >> >> I just upgraded Sid and now I get the following during boot: >> >> [] Configuring network interfaces.../etc/init.d/rpcbind: 42: >> /etc/init.d/rpcbind: stat: not found >> /run/rpcbind not owned by root failed! >> Starting NFS common utilities: statd >> Not starting: portmapper is not running ... (warning). >> mount.nfs: rpc.statd is not running but is required for remote locking. >> mount.nfs: Either use '-o nolock' to keep locks local, or start statd. >> mount.nfs: rpc.statd is not running but is required for remote locking. >> mount.nfs: Either use '-o nolock' to keep locks local, or start statd. >> done. >> [ ok ] Starting RPC port mapper daemon: rpcbind. >> [ ok ] Starting NFS common utilities: statd. > > The problem is caused by wrong setting of the PATH variable during the > execution of the /etc/init.d/rpcbind script. The new version uses stat > binary which is located in /usr/bin but the PATH is set to > PATH='/sbin:/bin'. This leaves the question why PATH is set that way. > As a workaround I added PATH="$PATH:/usr/bin" to > /etc/init.d/rpcbind. It works fine now. > > Please fix init scripts. Wouldn't it be better to fix the init system that sets such a bad default PATH? Whatever init system that may be - sysv-rc's /etc/init.d/rc script sets PATH=/sbin:/usr/sbin:/bin:/usr/bin, so this should not happen with sysvinit + sysv-rc. What init system do you use? Cheers, Sven
Re: Sid: NFS after upgrade [solved] please fix /etc/init.d/rpcbind
On 10/28/18 11:27 AM, Grzesiek Sójka wrote: Hi there, I just upgraded Sid and now I get the following during boot: [] Configuring network interfaces.../etc/init.d/rpcbind: 42: /etc/init.d/rpcbind: stat: not found /run/rpcbind not owned by root failed! Starting NFS common utilities: statd Not starting: portmapper is not running ... (warning). mount.nfs: rpc.statd is not running but is required for remote locking. mount.nfs: Either use '-o nolock' to keep locks local, or start statd. mount.nfs: rpc.statd is not running but is required for remote locking. mount.nfs: Either use '-o nolock' to keep locks local, or start statd. done. [ ok ] Starting RPC port mapper daemon: rpcbind. [ ok ] Starting NFS common utilities: statd. The problem is caused by wrong setting of the PATH variable during the execution of the /etc/init.d/rpcbind script. The new version uses stat binary which is located in /usr/bin but the PATH is set to PATH='/sbin:/bin'. As a workaround I added PATH="$PATH:/usr/bin" to /etc/init.d/rpcbind. It works fine now. Please fix init scripts. -- Pozdrawiam Grzesiek Wysłane z kompa wolnego od wirusów Billa Gatesa.
Sid: NFS after upgrade
Hi there, I just upgraded Sid and now I get the following during boot: [] Configuring network interfaces.../etc/init.d/rpcbind: 42: /etc/init.d/rpcbind: stat: not found /run/rpcbind not owned by root failed! Starting NFS common utilities: statd Not starting: portmapper is not running ... (warning). mount.nfs: rpc.statd is not running but is required for remote locking. mount.nfs: Either use '-o nolock' to keep locks local, or start statd. mount.nfs: rpc.statd is not running but is required for remote locking. mount.nfs: Either use '-o nolock' to keep locks local, or start statd. done. [ ok ] Starting RPC port mapper daemon: rpcbind. [ ok ] Starting NFS common utilities: statd. Thus NFS directories are not mounted automatically during boot. But, after booting the command: mount -at nfs works perfectly. Moreover: # rpcinfo localhost program version netid addressserviceowner 104tcp 0.0.0.0.0.111 portmapper superuser 103tcp 0.0.0.0.0.111 portmapper superuser 102tcp 0.0.0.0.0.111 portmapper superuser 104udp 0.0.0.0.0.111 portmapper superuser 103udp 0.0.0.0.0.111 portmapper superuser 102udp 0.0.0.0.0.111 portmapper superuser 104local /run/rpcbind.sock portmapper superuser 103local /run/rpcbind.sock portmapper superuser 1000241udp 0.0.0.0.171.0 status 103 1000241tcp 0.0.0.0.162.173status 103 1000211udp 0.0.0.0.168.197nlockmgr superuser 1000213udp 0.0.0.0.168.197nlockmgr superuser 1000214udp 0.0.0.0.168.197nlockmgr superuser 1000211tcp 0.0.0.0.141.197nlockmgr superuser 1000213tcp 0.0.0.0.141.197nlockmgr superuser 1000214tcp 0.0.0.0.141.197nlockmgr superuser # egrep -v '^$|^#' /etc/default/nfs-common NEED_STATD=yes STATDOPTS= NEED_IDMAPD=no NEED_GSSD= # ll /run/rpc* -d -rw-r--r-- 1 root root 0 Oct 28 11:06 /run/rpc.statd.lock -rw-r--r-- 1 statd nogroup 5 Oct 28 11:06 /run/rpc.statd.pid drwxr-xr-x 2 _rpc root40 Oct 28 11:06 /run/rpcbind -r--r--r-- 1 root root 0 Oct 28 11:06 /run/rpcbind.lock -rw-r--r-- 1 root root 4 Oct 28 11:06 /run/rpcbind.pid srw-rw-rw- 1 root root 0 Oct 28 11:06 /run/rpcbind.sock Any ideas?? -- Pozdrawiam Grzesiek Wysłane z kompa wolnego od wirusów Billa Gatesa.