[Bug 649591] Re: mountall spins eating cpu when 'nobootwait' option exists in fstab followed by a comma

[Scott Moser]

I did a local build of the proposed merge, and tested that it fixes the issue.
Additionally, I have a build pending in my ppa with that also.

This is ready for someone to sponsor to lucid-proposed, but I cannot do
the upload myself.

-- 
mountall spins eating cpu when 'nobootwait' option exists in fstab followed by a comma
https://bugs.launchpad.net/bugs/649591
You received this bug notification because you are a member of Ubuntu
Sponsors Team, which is a direct subscriber.

Status in “mountall” package in Ubuntu: Fix Released
Status in “mountall” source package in Lucid: Triaged
Status in “mountall” source package in Maverick: Fix Released

Bug description:
Binary package hint: mountall

As reported at [1], mountall is eating cpu cycles on reboot of both 10.04 (images 20100923 and later) and 10.10.

I believe the issue is related to changes made under bug 634102.

Here is what happens:
- The images are created with an fstab like:
 | proc              /proc  proc nodev,noexec,nosuid 0       0
 | LABEL=uec-rootfs  /      ext4 defaults   0 0
- On first boot, cloud-init writes additional entries like:
 | /dev/sda2   /mnt auto defaults,nobootwait,comment=cloudconfig 0 2
 | /dev/sda3   none swap sw,comment=cloudconfig  0 0
- On reboot, mountall will be eating CPU. and /mnt will *not* be mounted.
- removing the 'nobootwait' flag, and rebooting will result in system functioning properly

I've modified /etc/init/mountall and added '--debug' and '--verbose', and rebooted and collected the console log.

I believe the issue only presents itself when the device exists at boot and the 'nobootwait' flag is present.

I can boot 2 different instance types,
 m1.small : has /dev/sda2 and /dev/sda3
 t1.micro : does not have /dev/sda2 or /dev/sda3

mountall will spin in m1.small, but not in t1.micro.

I'm attaching the output of debug boot on m1.small (where /dev/sda2 does exist and mountall spins).

--
[1] http://groups.google.com/group/ec2ubuntu/browse_thread/thread/d415746dff066f06

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: mountall 2.17
ProcVersionSignature: User Name 2.6.35-22.33-virtual 2.6.35.4
Uname: Linux 2.6.35-22-virtual i686
Architecture: i386
Date: Tue Sep 28 06:45:14 2010
Ec2AMI: ami-307d8859
Ec2AMIManifest: ubuntu-images-testing-us/ubuntu-maverick-daily-i386-server-20100927.manifest.xml
Ec2AvailabilityZone: us-east-1c
Ec2InstanceType: m1.small
Ec2Kernel: aki-407d9529
Ec2Ramdisk: unavailable
ProcEnviron:
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: mountall

==== SRU Information ====
- Impact: On EC2 or UEC, due to how cloud-init writes fstab entries, on first reboot mountall will eat all CPU cycles.  On other systems, a user who updates /e
c/fstab seemingly correct will have mountall spin the first time it runs.
- How it was addressed: Logic error in cut_options routine in mountall was fixe
.  The code segment was easily removed and tested against different strings to verify no regressions.
- Patch: A branch has been linked with the same patch as used in maverick.
  lp:~smoser/ubuntu/lucid/mountall/bug649591
- How to reproduce:
  Edit an existing entry in /etc/fstab for which there is an existing device.  Change the options field to contain 'nobootwait,' in front of what was previously there.  Reboot.  You will now see mountall consuming resources.
- Regression: The most likely regression would be either failure of mountall to mount a device or segfault in mountall.  That said, the patch was tested well, and Colin had a strong understanding of the cause.
==== End SRU Information ====