mountall generates duplicate 'mounting' events for in-progress network mounts
Bug #1048017 reported by
Steve Langasek
This bug affects 1 person
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| mountall (Ubuntu) |
Fix Released
|
Medium
|
Unassigned | ||
Bug Description
Unlike local mounts, network mounts are handled asynchronously by mountall. As a result, if a SIGUSR1 (network device up) signal comes in while a mount is already in progress, mountall will generate a second, spurious 'mounting' event for the device. It does not appear to go so far as to spawn a redundant mount process, fortunately, but at least in the case of nfs mounts this results in extra calls to the statd-mounting job.
I noticed this in the process of applying the fix for bug #643289, the patch for which actually seems to improve the situation (only 3 mount attempts on boot for my test nfs filesystem, instead of 5).
| Changed in mountall (Ubuntu): | |
| status: | New → Triaged |
| importance: | Undecided → Medium |
| Changed in mountall (Ubuntu): | |
| status: | Triaged → Fix Committed |
Revision history for this message
| Launchpad Janitor (janitor) wrote | #1 |
| Changed in mountall (Ubuntu): | |
| status: | Fix Committed → Fix Released |
To post a comment you must log in.
This bug was fixed in the package mountall - 2.52
---------------
mountall (2.52) unstable; urgency=low
* Don't emit extra 'mounting' events for mounts already in progress; this
will cause double triggering of some jobs for remote filesystems, and
can also cause us to miss 'mounted' events. LP: #1048017.
* Fix mountall upstart job to not start a subshell for reading
/proc/cmdline, since this causes upstart to lose track of the daemon
process and leaves mountall-net unable to signal it to retry network
mounts. LP: #1235013.
-- Steve Langasek <email address hidden> Wed, 09 Oct 2013 04:12:51 +0000