[Bug 1181528] Re: /etc/init.d/umountroot: 'mount / is busy' due to upstart log file

[Steve Dodd]

*** This bug is a duplicate of bug 1181789 ***
    https://bugs.launchpad.net/bugs/1181789

Easily reproduced here, by (a) having two or more non-root filesystems
mounted, (b) deleting all *pack files from /var/lib/ureadahead. The
second reboot will fail to unmount the root.

The patch I've added to bug #1181789 seems to be the correct answer, but
the attached patch to the ureadahead upstart job should be an effective
workaround with no side effects.

** Patch added: "Temporary workaround patch for /etc/init/ureadahead-other"
   https://bugs.launchpad.net/ubuntu/+source/ureadahead/+bug/1181528/+attachment/3713988/+files/hack.diff

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to ureadahead in Ubuntu.
https://bugs.launchpad.net/bugs/1181528

Title:
  /etc/init.d/umountroot: 'mount / is busy' due to upstart log file

Status in “ureadahead” package in Ubuntu:
  Confirmed

Bug description:
  Steve Langasek insisted that this bug must be reported to ureadahead.
  I am almost sure that it resides somewhere else, but  I run out of ideas.
  This is another brunch of the Bug lp: #1073433
  'Ext4 corruption associated with shutdown of Ubuntu 12.10'
  Anyway inability to clearly remount root filesystem readonly is a serious issue.

  During shutdown /etc/init.d/umountroot reports
    mount: / is busy
  it leads to filesystem recovery next boot.

  It happens due to a file opened by upstart:
  init         1            root   12w      REG        8,2      344    2886145 /var/log/upstart/ureadahead-other.log
  (reported by lsof)

  For some reason init (upstart) decides that for the third filesystem
  there is a fork of ureadahed.

  [   19.563541] init: ureadahead-other main process (912)
  [   19.566832] init: ureadahead-other main process (912) executable changed
  [   19.619194] init: ureadahead-other main process (912) terminated with status 4
  [   19.621332] init: ureadahead-other goal changed from start to stop
  [   19.623678] init: ureadahead-other state changed from spawned to stopping
  [   19.628290] init: ureadahead-other state changed from stopping to killed
  [   19.630631] init: ureadahead-other state changed from killed to post-stop
  [   19.632954] init: ureadahead-other state changed from post-stop to waiting
  [   21.787397] init: ureadahead-other goal changed from stop to start
  [   21.789750] init: ureadahead-other state changed from waiting to starting
  [   21.794433] init: ureadahead-other state changed from starting to pre-start
  [   21.796985] init: ureadahead-other state changed from pre-start to spawned
  [   21.800622] init: ureadahead-other main process (920)
  [   21.803883] init: ureadahead-other main process (920) became new process (921)
  [   21.805935] init: ureadahead-other state changed from spawned to post-start
  [   21.808597] init: ureadahead-other state changed from post-start to running

  later initctl status ureadahead-other reports
  the process that is absent in ps output.

  I would expect that the second ureadahead-other process
  must exit with status 4 since there is no pack file.
  /var/log/upstart/ureadahead-other.log:

  ureadahead:/var/lib/ureadahead/home.pack: No such file or directory
  ureadahead:/var/lib/ureadahead/srv.pack: No such file or directory

  The bug also appears if there are pack and home.pack files but no srv.pack.
  Init does not hold log file if there pack files for all mounted filesystems.
  Perhaps the easiest way is to try mainline kernel that does not support
  file tracing required for ureadahead (to avoid creation of pack files
  during debug).

  I am in doubt if someone can easily reproduce this bug although
  I see it each boot under certain conditions.

  The bug appears for 3 filesystems in /etc/fstab (/ /home /srv in my case).
  I never seen it when just / and /home were mounted.
  In my case / is ext4, the others are ext3.

  The last time the bug disappeared after I removed /srv/mnt directory
  from / filesystem (when /srv was not mounted). Now even srv.pack
  is not required, just pack and home.pack is enough. But the first
  boot when there were no pack files finished with busy /.

  I have tried another partition instead of regularly mounted /srv.
  There was no bug if that partition was mounted to /mnt
  instead of /srv. The bug likes 'acl' in the mount options.

  I do not know why mysterious fork happens during second call
  of ureadadead-other, I can not reproduce it lunching ureadahead
  from command line under strace.

  Versions:
  Ubuntu 13.10 Raring, i686
  ureadahead: 0.100.0-16
  upstart: 1.8-0ubuntu1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ureadahead/+bug/1181528/+subscriptions