Comment 10 for bug 555661

On Tue, 2010-04-20 at 13:37 +0000, Steve Langasek wrote:
>
> Yes, I was asking if it logged anything before it died.

Doesn't appear to have.

> Yes, because upstart has been confused into thinking it's running when
> it isn't.

But why should upstart be able to determine that it's not actually
running and either walk through the stop anyway, or noop it, rather than
hanging indefinitely in the stop operation? That's the real nature of
this particular bug.

> > if [ "x$NEED_STATD" != xno ]; then
> > ls -l /var/lib/nfs >&2 || true
> > exec rpc.statd -L $STATDOPTS
> > fi
>
> Er, this will *definitely* fail. Because this script is marked 'expect
> fork', it will track the first child process that's forked off by the
> script - in this case, ls - and consider *that* to be the service.

~bleah~

> Why
> is this 'ls' command here?

To try to get more clarification on this /var and statd racing issue.

> Ah; that'll be the root cause of your boot-time failure, then. What's
> the bug number for this issue?

#525154.

> It should be a bug on nfs-utils.

It is. I posted some requested info back in Feb. but nothing was done
with it.

> There are two conflicting use cases here - one where /var is a separate
> local filesystem, and one where root is on NFS. When using nfsroot, we
> *can't* wait for the 'local-filesystems' event, as doing so blocks the
> root filesystem from ever being set up correctly by mountall.

Right. I did not advocate waiting for local-filesystem but rather
waiting for "mounted=/var/lib/nfs" (something that does not currently
exist afaik, hence my explanation as to how I thought such a thing would
work).

The nfsroot is a somewhat special case though in that you don't really
mount the nfsroot as / but typically you mount it somewhere else and
then pivot to it. I'm not really sure where the mountall runs in all of
that but I would think after the pivot is done during normal processing
of a post-/ mount. If /var is expected to be nfs mounted at that point
also, then I think you are stuck as you say in
https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/525154/comments/3. So maybe this use case is simply invalid. I'm really not sure TBH. Although it would be a shame as I can see reasons for such a use case.

> I think the case where the system unrecoverably hangs on boot (the
> nfsroot case) has to take precedence here. For your case, you should be
> able to edit /etc/init/statd.conf as you describe to be 'start on
> portmap and mounted MOUNTPOINT=/var"; except that this won't stop
> mountall from trying to mount NFS mounts in parallel at boot time, so if
> you have such mounts that will fail if statd isn't running, that still
> doesn't solve your problem.

Yeah. And what happens in the case where /var is not separate but on /?
Will that mounted MOUNTPOINT=/var cause the statd init job to not run
because there is no /var to be mounted? If so, we have not really
solved the problem in a universal and generic method.