10mount: umount: /<<CHROOT>>/dev: device is busy

Status changed to 'Confirmed' because the bug affects multiple users.

This bug report does not mention exactly what the device is which couldn't be umounted. Note that if we can't umount, we don't end the session, or else we could end up leaking resources e.g. LVM snapshots, which would also be quite annoying.

Please could you provide: the result of 'cat /proc/mounts' when you reproduce the problem.

Also, as the message stated, the output of 'lsof' would also be helpful.

output of cat /proc/mounts

output of lsof

on another ubuntu machine (oneiric server) i get leftover mounts like:
proc on /var/lib/schroot/mount/bootstrap-administrator-1b79165b-24ab-4a6d-8460-4f1ca45927d8/proc type proc (rw)
/dev/pts on /var/lib/schroot/mount/bootstrap-administrator-1b79165b-24ab-4a6d-8460-4f1ca45927d8/dev/pts type none (rw,bind)
proc on /var/lib/schroot/mount/bootstrap-administrator-a9d4e330-6451-41f9-889b-e70ecbcd5cb1/proc type proc (rw)
/dev/pts on /var/lib/schroot/mount/bootstrap-administrator-a9d4e330-6451-41f9-889b-e70ecbcd5cb1/dev/pts type none (rw,bind)

unmounting them gives a warning message

administrator@jenkins-server:~$ sudo umount /var/lib/schroot/mount/bootstrap-administrator-a9d4e330-6451-41f9-889b-e70ecbcd5cb1/dev/pts
[sudo] password for administrator:
umount: /var/lib/schroot/mount/bootstrap-administrator-a9d4e330-6451-41f9-889b-e70ecbcd5cb1/dev/pts: not found

 then the entry is gone from mount

I'm on 12.04

in my case I'm seeing libvirtd continuesly respawning and mounting the device some how.
umount /var/lib/schroot/mount/precise-2d97fb31-1cae-47e4-a363-0a652a518610/dev
root@bork:~# lsof | grep /var/lib/schroot/mount/precise-2d97fb31-1cae-47e4-a363-0a652a518610/dev
dbus-daem 19780 messagebus 0u CHR 1,3 0t0 5826 /var/lib/schroot/mount/precise-2d97fb31-1cae-47e4-a363-0a652a518610/dev/nul
tgtd 19794 root 0u CHR 1,3 0t0 5826 /var/lib/schroot/mount/precise-2d97fb31-1cae-47e4-a363-0a652a518610/dev/null
libvirtd 19913 root 0r CHR 1,3 0t0 5826 /var/lib/schroot/mount/precise-2d97fb31-1cae-47e4-a363-0a652a518610/dev/null

usually attempting to kill the processes just ends up in them respawning and magically remounting the directories. I can tell this by
I see message in dmesg to the effect of libvirt-bin terminated. Then right below it I see another message saying libvirtd-bin process e ended respawning.

The main culprits is usually udev though.

rebooting is problematic too if the schroot daemon picks up old sessions in the /var/lib/schroot/sessions directory and mounts those directories. :|

Seems the only sure fire way I've found is to delete the sessions directory and reboot. then I can umount them. And yes they misteresly are mounted some how.

I can't ease the schroots root directory unless I do this process and I was useing schroot so I could quickly ease a linux environment and start from scratch. Whats the status on this bug. It seems like the inability to forcefully umount the directories is the main cause of head ache.

possibly related to debian bug #681884 schroot: Does not always clean up after itself
repro'd this gaming in a schroot with mounts that opened in both chroot namespaces causing failure to tidily exit

@barry - do you use lvm with schroot? I do and I am also affected by this bug.

 $ schroot -e --all-sessions
E: 10mount: umount: /var/lib/schroot/mount/saucy-amd64-29694a5f-0def-40d4-9d3d-95bc27fa70f7: device is busy.
E: 10mount: (In some cases useful info about processes that use
E: 10mount: the device is found by lsof(8) or fuser(1))
E: saucy-amd64-29694a5f-0def-40d4-9d3d-95bc27fa70f7: Chroot setup failed: stage=setup-stop

from /proc/mounts:

/dev/mapper/virtual--vg-saucy--amd64--29694a5f--0def--40d4--9d3d--95bc27fa70f7 /var/lib/schroot/mount/saucy-amd64-29694a5f-0def-40d4-9d3d-95bc27fa70f7 ext4 rw,noatime,data=ordered 0 0

I wonder if this is related to bug 1223576 at all.

On Sep 12, 2013, at 05:30 PM, Brian Murray wrote:

>@barry - do you use lvm with schroot?

I actually don't, but I do sometimes see error messages like this. Nothing
actually bad happens afaict. A reboot then `schroot -e --all-sessions`
usually clears things up.

Brian Murray:
> I wonder if this is related to bug 1223576 at all.

I would highly suspect so; schroot has been plagued with lvremove failures for some time, and this looks like a likely candidate for why lvremove was failing--all the symptoms are suspiciously similar. If so, I'll be very happy--not being able to do anthing to fix it myself was quite frustrating.

Regards,
Roger

Bug 1223576 is not fixed in Saucy and I have not encountered this issue again, however I have not built a lot of packages.

I meant is now fixed in Saucy.