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. -- sudo service statd start does not return https://bugs.launchpad.net/bugs/555661 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
