Comment 7 for bug 613825

Apparently the upstart behaviour described here is as designed. See discussion below from the upstart-devel mailing list. That being the case, I think the fix I have already posted may be the best one available.

Scott James Remnant scott at netsplit.com
Wed Sep 1 13:31:33 BST 2010

    * Previous message: Behaviour of mounting event
    * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

On Tue, 2010-08-31 at 13:34 +0100, Scott James Remnant wrote:

> On Fri, 2010-08-27 at 23:30 +1000, Andrew Edmunds wrote:
>
> > Suppose I have a job B which includes the following stanza:
> >
> > start on (started A or mounting MOUNTPOINT=/m)
> >
Ah, sorry, for some reason I read "and" here - using "or" like this, the
following would be an expected behaviour.

> > It seems that the following sequence of events can occur:
> > 1. "started A" event is emitted
> > 2. Job B starts
> > 3. "mounting MOUNTPOINT=/m" event is emitted
> > 4. "mounting MOUNTPOINT=/m" event completes
> > 5. mountall attempts to mount /m
> > 6. Job B's main process is started
> > 7. Job B is marked as "running"

Scott
--
Have you ever, ever felt like this?
Had strange things happen? Are you going round the twist?

----------

Andrew Edmunds Andrew.Edmunds at yahoo.com.au
Wed Sep 1 12:21:31 BST 2010

Scott,

The job I'm interested in is Ubuntu's statd. The real start condition is:
start on (started portmap or mounting TYPE=nfs)

For an example where this seems to be misbehaving see boot.log and
syslog attached to:
https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/613825

Here is an edited version with line numbers added to show what I mean.

[boot.log]
159 init: portmap state changed from post-start to running
167 init: statd goal changed from stop to start
179 init: statd state changed from starting to pre-start^M^M
180 init: statd pre-start process (686)
598 init: event_new: Pending mounting event
602 init: Handling mounting event^M^M
603 init: event_pending_handle_jobs: New instance statd^M^M
604 init: event_finished: Finished mounting event^M^M
605 mounting /multimedia^M
628 spawn: mount -t nfs -o _netdev diskbox.local:/share/multimedia
/multimedia
642 spawn: mount /multimedia [742]
706 mount.nfs: rpc.statd is not running but is required for remote locking.
707 mount.nfs: Either use '-o nolock' to keep locks local, or start statd.

[syslog]
906 Aug 5 20:33:55 tvbox rpc.statd[773]: Version 1.1.6 Starting
907 Aug 5 20:33:55 tvbox rpc.statd[773]: Flags:
995 Aug 5 20:33:55 tvbox init: statd state changed from post-start to
running

It seems pretty clear that the mounting events here do not block and
wait for statd to reach the running state. statd is finally running at
syslog line 995 but this is long after the last attempt by mountall to
mount the NFS filesystem.

----------

Scott James Remnant scott at netsplit.com
Tue Aug 31 13:34:09 BST 2010

On Fri, 2010-08-27 at 23:30 +1000, Andrew Edmunds wrote:

> Suppose I have a job B which includes the following stanza:
>
> start on (started A or mounting MOUNTPOINT=/m)
>
> It seems that the following sequence of events can occur:
> 1. "started A" event is emitted
> 2. Job B starts
> 3. "mounting MOUNTPOINT=/m" event is emitted
> 4. "mounting MOUNTPOINT=/m" event completes
> 5. mountall attempts to mount /m
> 6. Job B's main process is started
> 7. Job B is marked as "running"
>
This is wrong; the correct sequence should be 1, 2, 3, 6, 7, 4, 5

If you're seeing the above, there's a problem somewhere - could you
attach your job configuration file?

Scott
--
Have you ever, ever felt like this?
Had strange things happen? Are you going round the twist?

----------

Andrew Edmunds Andrew.Edmunds at yahoo.com.au
Fri Aug 27 14:30:46 BST 2010

Hi,

Suppose I have a job B which includes the following stanza:

start on (started A or mounting MOUNTPOINT=/m)

It seems that the following sequence of events can occur:
1. "started A" event is emitted
2. Job B starts
3. "mounting MOUNTPOINT=/m" event is emitted
4. "mounting MOUNTPOINT=/m" event completes
5. mountall attempts to mount /m
6. Job B's main process is started
7. Job B is marked as "running"

So the "start on" stanza fails to guarantee that job B is actually
running before /m is mounted.

mounting(7) says that mountall will "wait for all services started by
this event to be running ... before proceeding with mounting the
filesystem." The above behaviour is consistent with that, since job B
was not triggered by the mounting event. However, the behaviour doesn't
seem very useful. I would suggest that mountall needs to wait until all
services that *would be* started by this event are running, even if they
were actually started by something else.

Can anyone comment on why it wasn't implemented that way?

Can someone suggest how to change the start condition to get the
desired behaviour?

I realise that the mounting event is defined by mountall but I think the
relevant logic about which events block which others is inside
upstart(?). And I couldn't find a mailing list for mountall anyway so I
decided to try asking here.