mountall 100% cpu ussage

Bug #1087951 reported by karaluh on 2012-12-08
This bug affects 1 person
Affects Status Importance Assigned to Milestone
mountall (Ubuntu)

Bug Description

After loging in to KDE I see 100% cpu ussage by mountall. I don't konow the exact case, but I suspect AoE or loop devices. Also, it doesn't happen on every boot and started several days ago. Previously it ocasionaly used to freeze at boot. I'm not 100% sure those two issues are related, however since the high cpu ussage started to come out I never experienced boot freeze again.

ProblemType: Bug
DistroRelease: Ubuntu 12.10
Package: mountall 2.42ubuntu0.2
ProcVersionSignature: Ubuntu 3.5.0-20.31-generic
Uname: Linux 3.5.0-20-generic i686
NonfreeKernelModules: nvidia
ApportVersion: 2.6.1-0ubuntu9
Architecture: i386
Date: Sat Dec 8 10:47:44 2012
InstallationDate: Installed on 2012-05-12 (209 days ago)
InstallationMedia: Kubuntu 12.04 LTS "Precise Pangolin" - Release i386 (20120423)
MarkForUpload: True
 PATH=(custom, no user)
SourcePackage: mountall
UpgradeStatus: Upgraded to quantal on 2012-11-16 (21 days ago)

karaluh (karaluh) wrote :
Steve Langasek (vorlon) wrote :

Thanks for the report. Interesting to know that you used to see freezes at boot and are now seeing 100% cpu usage... sounds like a step forward to me!

AoE seems quite possible as a culprit. Can you please attach your /etc/fstab to this report?

Also, please replace the 'exec' line in /etc/init/mountall.conf on your system with the following:

    exec mountall --verbose --daemon $force_fsck $fsck_fix > /run/mountall.log 2>&1

Then reproduce the error, and attach the resulting /run/mountall.log file.

Changed in mountall (Ubuntu):
importance: Undecided → High
status: New → Incomplete
karaluh (karaluh) wrote :

Follow-up: there's some race condition in play here, because the bug doesn't manifest itself on each boot. Here's my fstab, I would also like to note, that the AoE device is offline. I replaced the exec line and post the log ASAP.

karaluh (karaluh) wrote :

Ok, the bug manifested itself today again, but the log is 33 MB. A I suspected, the loop devices seems to be the problem. Those are CD images,and are mounted read only. Mountall warns about it and tries to remount them in endless loop. I don't know why it happens only occasionally though.

Changed in mountall (Ubuntu):
status: Incomplete → New
Steve Langasek (vorlon) wrote :

Well, I still need to see the exact log file to diagnose exactly what's going on. If the file is too big to attach, you can compress it and attach it, or you can give me just the first 1000 lines.

Changed in mountall (Ubuntu):
status: New → Incomplete
karaluh (karaluh) wrote :
Changed in mountall (Ubuntu):
status: Incomplete → New

On Sun, Feb 10, 2013 at 08:11:19AM -0000, karaluh wrote:
> ** Attachment added: "First 1000 lines of the log"

Thanks, this is interesting. Can you also attach your /etc/mtab? (This
will help narrow down the problem so I can start trying to reproduce it
without having to completely duplicate your set of mounts.)

karaluh (karaluh) wrote :
Steve Langasek (vorlon) wrote :

Thanks. Could you also attach the contents of /proc/self/mountinfo? This may display the mounts differently and is actually the more authoritative source that mountall references when trying to figure out if a mount is done.

karaluh (karaluh) wrote :

Any idea why Starcraft 2 ISO is mounted rw? Is this related, or should I file another bug?

karaluh (karaluh) wrote :

Also: Launchpad is broken and I cannot attach the file, which doesn't matter because it's empty.

Steve Langasek (vorlon) wrote :

I don't know why starcraft_ii is mounted rw, but I suspect it *is* related. It's also the only one of the filesystems that's of type udf rather than iso9660.

If you comment out the starcraft_ii mount in /etc/fstab, can you still reproduce the problem?

FWIW, I've tested here with a single loop-mounted iso and the problem is so far not reproducible for me using mountal 2.47 from raring.

> Also: Launchpad is broken and I cannot attach the file, which doesn't matter because it's empty.

/proc/self/mountinfo will never be empty. However, you may have trouble attaching files from /proc to bug reports using your browser. Can you try copying the output of 'cat /proc/self/mountinfo' into a comment instead?

Steve Langasek (vorlon) wrote :

Ok, I have managed to reproduce this problem (at least partially) by changing the order of filesystem preferences in /etc/fstab - listing iso9660,udf instead of udf,iso9660, when the image is indeed iso9660.

/home/ubuntu/raring-desktop-amd64.iso /mnt/starcraft iso9660,udf user,loop 0 0

In this case, mountall mounts it, then remounts it twice more, then exits. So the infinite loop may be related to having multiple loopback filesystems in /etc/fstab.

Steve Langasek (vorlon) wrote :

On further inspection, the behavior I'm seeing may not be related at all; the remounting is only done because of a perceived mismatch between ro,rw options, and there's no mention of 'remounting' in your own log.

Steve Langasek (vorlon) wrote :

/dev/etherd/e0.0 /mnt/backup/ ext3 relatime 0 0

So, this doesn't explain why mountall is in an infinite loop, but I notice that there's nothing in your log showing this filesystem coming up - mountall won't /finish/ until this filesystem becomes available. And it certainly wouldn't be available until after the network is up; so this filesystem should have the '_netdev' option set.

karaluh (karaluh) wrote :
Download full text (4.7 KiB)

I'm going to comment the AoE line and try to reproduce. Mountinfo bellow.

15 20 0:14 / /sys rw,nosuid,nodev,noexec,relatime - sysfs sysfs rw
16 20 0:3 / /proc rw,nosuid,nodev,noexec,relatime - proc proc rw
17 20 0:5 / /dev rw,relatime - devtmpfs udev rw,size=2045304k,nr_inodes=207136,mode=755
18 17 0:11 / /dev/pts rw,nosuid,noexec,relatime - devpts devpts rw,gid=5,mode=620,ptmxmode=000
19 20 0:15 / /run rw,nosuid,relatime - tmpfs tmpfs rw,size=822584k,mode=755
20 1 8:2 / / rw,relatime - ext4 /dev/disk/by-uuid/d873b110-6709-4b24-95b6-40d55deefe48 rw,errors=remount-ro,data=ordered
21 15 0:16 / /sys/fs/cgroup rw,relatime - tmpfs cgroup rw,mode=755
22 21 0:17 / /sys/fs/cgroup/cpuset rw,relatime - cgroup cgroup rw,cpuset
23 21 0:18 / /sys/fs/cgroup/cpu rw,relatime - cgroup cgroup rw,cpu
24 21 0:19 / /sys/fs/cgroup/cpuacct rw,relatime - cgroup cgroup rw,cpuacct
25 21 0:20 / /sys/fs/cgroup/memory rw,relatime - cgroup cgroup rw,memory
27 15 0:22 / /sys/fs/fuse/connections rw,relatime - fusectl none rw
26 21 0:21 / /sys/fs/cgroup/devices rw,relatime - cgroup cgroup rw,devices
28 15 0:6 / /sys/kernel/debug rw,relatime - debugfs none rw
30 15 0:10 / /sys/kernel/security rw,relatime - securityfs none rw ...


karaluh (karaluh) wrote :

Just reproduced it with AoE commented out. Next step: Starcraft 2 iso.

karaluh (karaluh) wrote :

Just reproduced with both Aoe and SCII commented out. What next?

Steve Langasek (vorlon) wrote :

Your original bug report is with mountall 2.42ubuntu0.2. The current version of mountall in quantal is 2.42ubuntu0.4. Have you upgraded to this version? If not, could you do so now and confirm whether the bug is still reproducible?

If it is reproducible with 2.42ubuntu0.4, I'll test again here. I think my testing up to this point has been with the raring version of mountall - that *should* be equivalent, but best to double-check.

karaluh (karaluh) wrote :

I upgraded and reproduced.

Helm (thehelm) wrote :

I have a similar problem, Ubuntu 12.04, mountall 2.36.4. I have a file-system (/data) with 44 sqfs-images and the mountpoints for them.

In the fstab I mount first the filesystem
/dev/vg2/datalv /data ext4 noatime 0 2

and later the images
/data/sqfs/xxxxx01.sqfs /data/xxxxx/xxxxx/xxxxx01 squashfs,ro loop 0 0
/data/sqfs/xxxxx44.sqfs /data/xxxxx/xxxxx/xxxxx44 squashfs,ro loop 0 0

I could reproduce the infinite running mountall with 100% CPU usage on about 2 out of 3 bootings.

The problem seems to go away after changing all lines in fstab containing sqfs to
/data/sqfs/xxxxx01.sqfs /data/xxxxx/xxxxx/xxxxx01 squashfs,ro,_netdev loop 0 0
(adding "_netdev", probably impossible workaround on a mobile computer)

So maybe mountall goes into the infinite loop while waiting on the availbility of the image-files, (*.iso or *.sqfs)?
I did not find any other option to make mount wait onto an other fs like waiting on the network.

Anders (eddiedog988) on 2014-03-13
Changed in mountall (Ubuntu):
status: New → Confirmed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers