init: portmap-wait (statd) main process (693) killed by TERM signal

[mahmood]

the client log says:
Apr 4 12:23:29 server init: portmap-wait (statd) main process (693) killed by TERM signal
Apr 4 12:23:29 server init: statd-mounting main process (679) killed by TERM signal
Apr 4 12:23:29 server rpc.statd[947]: Version 1.1.6 Starting
Apr 4 12:23:29 server rpc.statd[947]: Flags:

Although the mount points are defined in /etc/fstab, they don't mount upn boot. I have to mount them manually

[Steve Langasek (vorlon)]

Clint, any chance you could have a look at this?

[Clint Byrum (clint-fewbar)]

mahmood, thanks for the bug report!

This looks like the expected sequence, as portmap-wait will be killed once portmap has started, and statd-mounting will be killed once statd has "started". However, it looks like the statd job uses 'expect fork' to time its 'started' event. Since it also uses a script, this means as soon as the script has started running the started event is likely emitted, and the waiting mountall is allowed to go forward with the mount. I wonder if we don't need to switch to 'expect daemon', or use a post-start to watch for the daemon to be fully running.

Can you run 'apport-collect 776407' on this system to give us more information? Also it would be helpful if apport-collect doesn't add it, to attach a copy of /etc/fstab

Thank you!

[Steve Langasek (vorlon)]

> Since it also uses a script, this means as soon as the script
> has started running the started event is likely emitted,

This should not be the case. The script is:

        if [ -f "$DEFAULTFILE" ]; then
            . "$DEFAULTFILE"
        fi

        if [ "x$NEED_STATD" != xno ]; then
                exec rpc.statd -L $STATDOPTS
        fi

These are all shell builtins (by design) until rpc.statd execs. So the first fork is within rpc.statd.