This service will be undergoing maintenance at 20:00 UTC, 2017-04-03. It is expected to last about 30 minutes
Bug 227593 - hal don't see device removal
hal don't see device removal
Product: Fedora
Classification: Fedora
Component: hal (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: David Zeuthen
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2007-02-06 18:03 EST by Patrice Dumas
Modified: 2013-03-05 22:49 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 724034 (view as bug list)
Last Closed: 2007-03-01 04:04:28 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Patrice Dumas 2007-02-06 18:03:57 EST
Description of problem:

It is not completely reproducible, but in general when I add an usb
key, mount the key (using pmount, not through hal), remove the key 
without unmounting, hal becomes confused and don't see that the usb
key was removed. It is still confused after umounting as root the 

It seems to go much more smoothly when gnome-mount
is used to mount and umount -- even on a device that isn't connected

Version-Release number of selected component (if applicable):

The version before hal-, maybe hal-
I'll retest with last version. 

How reproducible:

Steps to Reproduce:
Actual results:

Expected results:

Additional info:

I may be missing something. I am ready to do more testing if 
this is really something that is to be looked at.
Comment 1 Patrice Dumas 2007-02-06 18:32:34 EST
A bit more on how to reproduce:

I have 2 partitions on my key (2 fat).
I do everything as root

--> insert key
# pmount-hal /dev/sdb1
# pumount /dev/sdb1
--> remove key

everything is right

--> insert key
# pmount-hal /dev/sdb1
--> remove key

only /dev/sdb2 has been removed from lshal. sdb1 still appears to be mounted,
volume.is_mounted = true  (bool)
volume.mount_point = '/media/usbdisk'  (string)

If, at that point i run
# umount /media/usbdisk
hal gets notified that the partition is unmounted, the above properties 
change to
volume.is_mounted = false  (bool)
volume.mount_point = ''  (string)

--> reinsert the key
If i reinsert the key hal don't see anything new (while a dmesg shows
that the kernel has detected the devices, and they are indeed in 
At that point it is still possible to mount /dev/sdb1
# pmount-hal /dev/sdb1
and hal even gets notified of volume.is_mounted and volume.mount_point

/dev/sdb2 cannot be mounted with hal, at that point, but can be mounted 
pmount /dev/sdb2
hal don't get notified of that mount (/dev/sdb2 is still missing
from lshal).
Comment 2 David Zeuthen 2007-02-06 19:29:38 EST
HAL will not unmount on device removal unless the device is mounted through HAL
(think what would happen if a huge SAN went offline; then HAL would unmount lots
of stuff that it shouldn't). As such this is not a bug.

You might be interested in knowing that Ubuntu is switching from pmount to
gnome-mount too.
Comment 3 Patrice Dumas 2007-02-06 19:52:48 EST
(In reply to comment #2)
> HAL will not unmount on device removal unless the device is mounted through HAL
> (think what would happen if a huge SAN went offline; then HAL would unmount lots
> of stuff that it shouldn't). As such this is not a bug.

The issue isn't that HAL don't unmount stuff, especially stuff that was
not mounted through HAL, I am perfectly fine with that. But it shouldn't 
ignore that a device has been removed (or inserted) just because it didn't 
mount a partition. And moreover it lost track of a partition that was never
mounted, and of the whole device. 

The same happens when bare mount is used. Mounting one of the partition
and then removing the usb key and, even though there is no device anymore
they still show up in hal. One could want to mount some partitions 
"by hand" and other through HAL. Another view is that hal isn't
really an hardware abstraction layer if it is tied to a given mount
procedure when it comes to detecting whether a device is present or not.
It seems definitely to be a bug to me, but maybe HAL has evolved and isn't
really an abstraction layer anymore, but something else.

> You might be interested in knowing that Ubuntu is switching from pmount to
> gnome-mount too.

Both are different and have interesting features. They are more complementary
than substitute in my opinion.
Comment 4 David Zeuthen 2007-02-06 22:28:31 EST
Can show me that there's an uevent for removal (use udevmonitor) and demonstrate
that hal ignores that event? Because, yea, that would be a bug we'd need to fix.

(yes, HAL is a bad name; the software right now called HAL it's an interface for
unprivileged desktop applications to interact with the system. It will get
renamed from HAL before it reaches version 1.0.)
Comment 5 Patrice Dumas 2007-02-07 04:10:40 EST
Seems like there are in fact 2 uevents for removal.

Here I mount:
UEVENT[1170838910.019338] mount@/block/sdb/sdb1
UDEV  [1170838910.022331] mount@/block/sdb/sdb1

Then I remove the usb key:
UEVENT[1170838919.201890] remove@/class/usb_endpoint/usbdev4.4_ep01
UDEV  [1170838919.201890] remove@/class/usb_endpoint/usbdev4.4_ep01
UEVENT[1170838919.201969] remove@/class/usb_endpoint/usbdev4.4_ep82
UEVENT[1170838919.201990] remove@/class/usb_endpoint/usbdev4.4_ep83
UEVENT[1170838919.202010] remove@/class/scsi_generic/sg2
UEVENT[1170838919.202030] remove@/class/scsi_device/2:0:0:0
UEVENT[1170838919.202050] remove@/class/scsi_disk/2:0:0:0
UEVENT[1170838919.202071] remove@/block/sdb/sdb2
UEVENT[1170838919.202091] remove@/block/sdb/sdb1
UEVENT[1170838919.202111] remove@/block/sdb
UEVENT[1170838919.202131] remove@/devices/pci0000:00/0000:00:1d.7/usb4/4-3/4-3:1
UEVENT[1170838919.202151] remove@/class/scsi_host/host2
UEVENT[1170838919.202171] remove@/devices/pci0000:00/0000:00:1d.7/usb4/4-3/4-3:1
UEVENT[1170838919.202195] remove@/class/usb_device/usbdev4.4
UEVENT[1170838919.202214] remove@/class/usb_endpoint/usbdev4.4_ep00
UEVENT[1170838919.202235] remove@/devices/pci0000:00/0000:00:1d.7/usb4/4-3
UDEV  [1170838919.206212] remove@/class/usb_endpoint/usbdev4.4_ep82
UDEV  [1170838919.208258] remove@/class/usb_endpoint/usbdev4.4_ep83
UDEV  [1170838919.210229] remove@/class/scsi_generic/sg2
UDEV  [1170838919.211666] remove@/class/scsi_device/2:0:0:0
UDEV  [1170838919.212080] remove@/class/scsi_disk/2:0:0:0
UDEV  [1170838919.217144] remove@/block/sdb/sdb2
UDEV  [1170838919.221177] remove@/block/sdb/sdb1
UDEV  [1170838919.223810] remove@/devices/pci0000:00/0000:00:1d.7/usb4/4-3/4-3:1
UDEV  [1170838919.226009] remove@/class/scsi_host/host2
UDEV  [1170838919.228636] remove@/class/usb_device/usbdev4.4
UDEV  [1170838919.231140] remove@/class/usb_endpoint/usbdev4.4_ep00
UDEV  [1170838919.247851] remove@/block/sdb
UDEV  [1170838919.250639] remove@/devices/pci0000:00/0000:00:1d.7/usb4/4-3/4-3:1
UDEV  [1170838919.253994] remove@/devices/pci0000:00/0000:00:1d.7/usb4/4-3

Hal still sees sdb and sdb1
$ lshal | grep sdb
  block.device = '/dev/sdb'  (string)
  linux.sysfs_path_device = '/sys/block/sdb'  (string)
  linux.sysfs_path = '/sys/block/sdb'  (string)
  block.device = '/dev/sdb1'  (string)
  linux.sysfs_path_device = '/sys/block/sdb/sdb1'  (string)
  linux.sysfs_path = '/sys/block/sdb/sdb1'  (string)

Comment 6 David Zeuthen 2007-02-07 12:57:49 EST
Sure, that's a bug. I'll try to look into it.
Comment 7 Patrice Dumas 2007-02-07 15:51:42 EST
If it is solved, then HAL could keep its name ;-)
Comment 8 David Zeuthen 2007-03-01 04:04:28 EST
Something like this patch;a=commitdiff;h=f5b862f5690106bb3d5500b1091d12f089bae070;hp=193b7bbb91cb56d5fa5e87e90382449a023b6915

should fix it. It was a pretty obvious mistake in HAL. This will hit Rawhide as
soon as I upload a new release so I'm closing this UPSTREAM. Feel free to reopen
if it doesn't fix it for you. Thanks.

Note You need to log in before you can comment on or make changes to this bug.