mounted-tmp uses 'find' -- but if /usr is not yet available it will fail

[C de-Avillez]

Binary package hint: upstart

upstart 0.6.6-3, Maverick.

There is a chance of a race if /tmp and /usr are different filesystems (in my case, it is almost certain mounted-tmp will fail). mounted-tmp starts on mounted /tmp, but no sync is done to verify if /usr is already mounted. Then, then the 'find' line is executed, it is hit by an error, and the script exits with RC=127.

Of course, if /usr not a filesystem per se, no problems.

[Clint Byrum (clint-fewbar)]

Carlos, thanks for the report. I can see where this will fail with a separate /usr. This is actually mountall's file though, not upstart's.

One just needs to use an OR and add a check:

start on (mounted MOUNTPOINT=/tmp) or (mounted MOUNTPOINT=/usr)

and then add this to the top

[ -x /usr/bin/find ] || exit 0

If /tmp is mounted before /usr, it will exit 0. if /usr is mounted before /tmp, then we'll just clear out the empty mount point for /tmp, which is actually a good thing. /tmp will be mounted later and we'll clear it out. If /tmp is not its own filesystem this also makes sure it gets cleaned up. Because mounted is a hook point, there's no parallelism to worry about.

Assigning to myself, merge proposal forthcoming.

[C de-Avillez (hggdh2)]

Hi Clint, sorry, I most certainly had upstart in my mind when I opened this bug -- so the mistake.

Thanks for the patch, I had bypassed it in a similar way, but not as elaborate. Just one comment -- it is quite rare, I agree, but what would happen if 'cd ${MOUNTPOINT}' fails -- whatever the reason?

Wouldn't it be safer to run the find on ${MOUNTPOINT} (or just plain '/tmp') instead of '.'? There is an implicit risk of data loss here.

Note that this is *not* the issue with the bug, just an additional point. I can open a new bug if you wish.

[Clint Byrum (clint-fewbar)]

The scripts are run with set -e, so cd failing will stop the script. Agreed that it's a little scary to leave that as the only protection.

On Feb 6, 2011, at 8:39 AM, C de-Avillez <email address hidden> wrote:

> Hi Clint, sorry, I most certainly had upstart in my mind when I opened
> this bug -- so the mistake.
>
> Thanks for the patch, I had bypassed it in a similar way, but not as
> elaborate. Just one comment -- it is quite rare, I agree, but what would
> happen if 'cd ${MOUNTPOINT}' fails -- whatever the reason?
>
> Wouldn't it be safer to run the find on ${MOUNTPOINT} (or just plain
> '/tmp') instead of '.'? There is an implicit risk of data loss here.
>
> Note that this is *not* the issue with the bug, just an additional
> point. I can open a new bug if you wish.
>
> --
> You received this bug notification because you are a direct subscriber
> of the bug.
> https://bugs.launchpad.net/bugs/655447
>
> Title:
> mounted-tmp uses 'find' -- but if /usr is not yet available it will
> fail
>
> Status in “mountall” package in Ubuntu:
> In Progress
>
> Bug description:
> Binary package hint: upstart
>
> upstart 0.6.6-3, Maverick.
>
> There is a chance of a race if /tmp and /usr are different filesystems
> (in my case, it is almost certain mounted-tmp will fail). mounted-tmp
> starts on mounted /tmp, but no sync is done to verify if /usr is
> already mounted. Then, then the 'find' line is executed, it is hit by
> an error, and the script exits with RC=127.
>
> Of course, if /usr not a filesystem per se, no problems.
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/655447/+subscribe

[Launchpad Janitor (janitor)]

This bug was fixed in the package mountall - 2.21

---------------
mountall (2.21) natty; urgency=low

  * conf/mounted-tmp.conf: find is needed from /usr, so delay this and
    try again when /usr is mounted. LP: #655447
 -- Clint Byrum <email address hidden> Fri, 04 Feb 2011 15:47:59 -0800