Comment 18 for bug 387161

Thanks! I looked at the strace and found some oddities:

1274 11:37:08.712674 readlink("/sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/sda1", 0xbfdd92cc, 1024) = -1 EINVAL (Invalid argument)

(lots of those); this is probably because the device disappears underneath.

I filtered out the "harmless" syscalls with

  egrep -v 'open|read|write|readlink|lstat|fstat|statfs|stat64|socket|close|gettimeofday|poll|access|getdent' dk-disks.trace |less

and couldn't really find anything weird which would cause the device to disappear/disconnect. No ioctl etc. at all. I also checked the source, the daemon does not do any ioctls.

So let's look at the timestamps. Everything until line 2368 is initialization, which isn't an issue here since the drive isn't even plugged in at this point. 2369 is the poll on the udev socket to wait for events.

20 seconds later (11:37:30.797517) there's the recvmsg() to read the uevent for adding sdb, followed by a lot of open() and readlink() on the new node in sysfs, to probe device attributes. Reading sysfs should be a valid operation.

The first non-read call is at 11:37:30.804971, but this is just a writev() to the udev socket, announcing the ADDED signal.

After that there's a similar uevent-probe-signal block for sdb1. This ends at line 2464, timestamp 11:37:30.855906.

Then there's another poll() for uevents, which immediately receives a removal signal from udev. So there is no syscall in between which could trigger this removal event. I suspected as much, but the strace confirms it.

I think a more likely candidate for this behaviour is the callouts in devkit's udev rules. Can folks please all re-install devicekit-disks, do

  sudo mv /lib/udev/rules.d/95-devkit-disks.rules{,.disabled}
  devkit-disks --dump # this will make sure that the daemon is running

then unplug and re-plug the drive, and check if the USB resets still happen then?

Thanks!