Comment 3 for bug 655447

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