sys_umount() returns EBUSY when doing: sh -c "mount /dev/sdc1 /mnt; umount /mnt"
Francis Moreau
I've some shell scripts which try to find out the filesystem hosted by
a block device.
They basically do this:
mount /dev/sdc1 /mnt
fs=$(stat -f -c %T $mount_point)
umount /mnt
It happens to work but since an unknown upgrade (kernel, libs or tools
upgrade), umount(8) returns -EBUSY.
I found that it's actually the sys_umount() which return -EBUSY.
So the question, is this expected or is this a regression ?
If it's expected then which operation should I add between the
mount(8) and umount(8) to make the mount operation completely finish
(inside the kernel) so the next umount won't return -EBUSY ?
Oh I'm currently using the kernel shipped with F12: 2.6.32.9-67.fc12.x86_64
Thanks
--
Francis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Robert Hancock
> Hello
>
> I've some shell scripts which try to find out the filesystem hosted by
> a block device.
>
> They basically do this:
>
> mount /dev/sdc1 /mnt
> fs=$(stat -f -c %T $mount_point)
> umount /mnt
>
> It happens to work but since an unknown upgrade (kernel, libs or tools
> upgrade), umount(8) returns -EBUSY.
>
> I found that it's actually the sys_umount() which return -EBUSY.
>
> So the question, is this expected or is this a regression ?
>
> If it's expected then which operation should I add between the
> mount(8) and umount(8) to make the mount operation completely finish
> (inside the kernel) so the next umount won't return -EBUSY ?
If no other process were involved I would say it's likely a bug.
However, my guess is that some other process (HAL, something in GNOME,
etc.) detects the mount and decides to start accessing the drive. Then
when you immediately try to unmount, it fails because it's busy. I
suspect if you try this in single-user mode with no unnecessary
processes running you won't see this.
>
> Oh I'm currently using the kernel shipped with F12: 2.6.32.9-67.fc12.x86_64
>
> Thanks
--
Francis Moreau
> On 03/13/2010 02:56 AM, Francis Moreau wrote:
>>
>> Hello
>>
>> I've some shell scripts which try to find out the filesystem hosted by
>> a block device.
>>
>> They basically do this:
>>
>> mount /dev/sdc1 /mnt
>> fs=$(stat -f -c %T $mount_point)
>> umount /mnt
>>
>> It happens to work but since an unknown upgrade (kernel, libs or tools
>> upgrade), umount(8) returns -EBUSY.
>>
>> I found that it's actually the sys_umount() which return -EBUSY.
>>
>> So the question, is this expected or is this a regression ?
>>
>> If it's expected then which operation should I add between the
>> mount(8) and umount(8) to make the mount operation completely finish
>> (inside the kernel) so the next umount won't return -EBUSY ?
>
> If no other process were involved I would say it's likely a bug. However, my
> guess is that some other process (HAL, something in GNOME, etc.) detects the
> mount and decides to start accessing the drive. Then when you immediately
> try to unmount, it fails because it's busy. I suspect if you try this in
> single-user mode with no unnecessary processes running you won't see this.
>
You're right, I don't see this anymore if I'm booting in a single user mode.
So I need to find out how to wait until these other processes stop
accessing the drive.
Thanks
--
Francis
Petr Uzel
> On Sun, Mar 14, 2010 at 5:21 PM, Robert Hancock <hanco...@gmail.com> wrote:
> > On 03/13/2010 02:56 AM, Francis Moreau wrote:
> >> Hello
> >>
> >> I've some shell scripts which try to find out the filesystem hosted by
> >> a block device.
> >>
> >> They basically do this:
> >>
> >> mount /dev/sdc1 /mnt
> >> fs=$(stat -f -c %T $mount_point)
> >> umount /mnt
> >>
> >> It happens to work but since an unknown upgrade (kernel, libs or tools
> >> upgrade), umount(8) returns -EBUSY.
> >>
> >> I found that it's actually the sys_umount() which return -EBUSY.
> >>
> >> So the question, is this expected or is this a regression ?
> >>
> >> If it's expected then which operation should I add between the
> >> mount(8) and umount(8) to make the mount operation completely finish
> >> (inside the kernel) so the next umount won't return -EBUSY ?
> >
> > If no other process were involved I would say it's likely a bug. However, my
> > guess is that some other process (HAL, something in GNOME, etc.) detects the
> > mount and decides to start accessing the drive. Then when you immediately
> > try to unmount, it fails because it's busy. I suspect if you try this in
> > single-user mode with no unnecessary processes running you won't see this.
> >
I have experienced something similar when I did addpart, immediately
followed by delpart. The delpart command failed with EBUSY, because
the first command triggered some hal subprocess that accessed the
device.
> You're right, I don't see this anymore if I'm booting in a single user mode.
You can try to put 'lsof /dev/sdc1' between mount and umount to see
what (if anything) is accessing the device.
>
> So I need to find out how to wait until these other processes stop
> accessing the drive.
If it is hal what causes EBUSY, you could 'killall -SIGSTOP haldaemon'
before mount and SIGCONT after umount.
Petr
--
Petr Uzel, openSUSE Boosters Team
IRC: ptr_uzl @ freenode