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.