|Summary:||hal don't see device removal|
|Product:||[Fedora] Fedora||Reporter:||Patrice Dumas <pertusus>|
|Component:||hal||Assignee:||David Zeuthen <davidz>|
|Status:||CLOSED UPSTREAM||QA Contact:|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|:||724034 (view as bug list)||Environment:|
|Last Closed:||2007-03-01 09:04:28 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description Patrice Dumas 2007-02-06 23:03:57 UTC
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 devices. It seems to go much more smoothly when gnome-mount is used to mount and umount -- even on a device that isn't connected anymore. Version-Release number of selected component (if applicable): The version before hal-0.5.8.1-8.fc7, maybe hal-0.5.8.1-7. I'll retest with last version. How reproducible: Steps to Reproduce: 1. 2. 3. 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 23:32:34 UTC
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 /dev/sdb*). 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 change. /dev/sdb2 cannot be mounted with hal, at that point, but can be mounted fine: pmount /dev/sdb2 hal don't get notified of that mount (/dev/sdb2 is still missing from lshal).
Comment 2 David Zeuthen 2007-02-07 00:29:38 UTC
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-07 00:52:48 UTC
(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-07 03:28:31 UTC
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 09:10:40 UTC
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 .0/host2/target2:0:0/2:0:0:0 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 .0 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 .0/host2/target2:0:0/2:0:0:0 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 .0 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 17:57:49 UTC
Sure, that's a bug. I'll try to look into it.
Comment 7 Patrice Dumas 2007-02-07 20:51:42 UTC
If it is solved, then HAL could keep its name ;-)
Comment 8 David Zeuthen 2007-03-01 09:04:28 UTC
Something like this patch http://gitweb.freedesktop.org/?p=hal.git;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.