Behaviour of mounting event

[Andrew Edmunds]

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 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)
>>
>> 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