On Sat, 2010-04-24 at 22:49 +0000, Steve Langasek wrote: > On Tue, Apr 20, 2010 at 02:10:56PM -0000, Brian J. Murrell wrote: > > 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;
If that same bug is what is stopping a "sudo service statd" from not returning, even after the machine is fully booted and all local filesytems, including /var are mounted, then I would think marking as a duplicate is fine. > but > that doesn't help with the very real bug in nfs-utils regarding the /var > race condition. Indeed, but that is bug #525154, so we can carry on that discussion there, yes? > You can, as a local admin, modify your /etc/init/statd.conf to set 'start on > mounted MOUNTPOINT=/var'. Yeah, but as I'm sure you understand, that doesn't scale very well. :-( > 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. Indeed, which I fully understand. Of course, my proposal was a "future" for upstart/mountall. > 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 Ahhh. So we are of like minds on this, which gives me a bit of reassurance that I am not on crack thinking about that. :-) > 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. Indeed. I was not sure who did what in terms of reading the conf files and whatnot, but I had fully realized that prior to mounting, mountall (or somebody) would have to use the fstab and the /etc/init/*.conf files to figure out all of the "path mounted" signals that are being waited for and should be sent. > So in short, we shouldn't let resolution of this bug block on the > availability of such a feature. Indeed, and I'd even be happy to just assume that /var/lib/nfs is on /var (as that would be the majority of the cases -- where /var is separate), and work with mounted MOUNTPOINT=/var, but that's incompatible with those that just put everything in /. Those seem like two incompatible cases and the admin that runs the (IMHO) "properly" partitioned system is going to have to touch every one of his systems to add the "mounted MOUNTPOINT=/var" dependency to his statd.conf files. I really know quite little about the workings of upstart at this point, but I wonder if some sort of temporary, outboard-of-mountall job can be written to emulate the functionality of scanning the .conf files for wanted paths, as well as the fstab and emitting signals when a mounted filesystem makes wanted paths available. So, for the case of /var being a seperate filesystem, given that my statd.conf already has: start on (started portmap or mount TYPE=nfs) what do I want to change that to do wait for /var to be mounted? Seems like I want: start on ((started portmap or mount TYPE=nfs) and mounted MOUNTPOINT=/var) but I don't know if parens are legal inside that statement. -- 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 ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs