On Tue, Apr 20, 2010 at 02:10:56PM -0000, Brian J. Murrell wrote: > > 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. That's the nature of an existing bug, already filed against the upstart package. If you want, I can mark this bug as a duplicate of that one; but that doesn't help with the very real bug in nfs-utils regarding the /var race condition. > > 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). You can, as a local admin, modify your /etc/init/statd.conf to set 'start on mounted MOUNTPOINT=/var'. There indeed is not a way to specify this that will work for arbitrary paths that may or may not actually be mountpoints (including /var), because we only get 'mounted' events for actual filesystems. It *would* be nice to be able to be able to specify in the default jobs that the job waits for a particular path, and I've asked Scott James Remnant for this in the past - but only in passing and at a much lower priority than a number of other critical bugs related to mountall this cycle, because it would require a two-way negotiation for upstart to let mountall know which particular points in the path it needs to send notifications for. So in short, we shouldn't let resolution of this bug block on the availability of such a feature. > 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. mountall runs after init starts. nfsroot may or may not be done using an initramfs - there's in-kernel support for nfsroot using static IP configuration. But we can reasonably assume that *if* someone is using nfsroot, then /var/lib is on the root filesystem, because that's the only way to make this work even pre-upstart. The problem lies entirely in trying to express a single job that works both for nfsroot and for non-nfsroot with /var as a separate partition. In the case of portmap, there's no trade-off; "start on virtual" is always correct. In the case of statd, there's a trade-off, and I think breaking nfsroot is the lesser evil when weighed against breaking /var partitions - especially since this was already the status quo for nfsroot systems prior to Apr 17. So for lucid, I'm still inclined to update the statd job to 'start on local-filesystems'. Possibly 'start on (local-filesystems and mounting TYPE=nfs)' - if that doesn't cause NFS mount attempts after the first one to deadlock in mountall/upstart. I'll have to test this and propose it as an SRU if it checks out. > > 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. Correct. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ [email protected] [email protected] -- 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
