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.