Hi, I am experiencing exactly the same problem. I have, so far, only managed to reliably reproduce it using these steps:
0. Lock the screen 1. Close the lid of my laptop, so that it suspends according to GNOME3's power settings 2. Wait a short while - the time it would normally take the fingerprint procedure to time-out (may not be necessary, not sure) 3. Re-open the lid, causing the laptop to wake up. Thus, it seems related to going in and out of S3 suspend. I have tried debugging it via what little D-Bus I know. Basically, the device is Claimed first by gdm (I assume...) as my username. Then, the UI sends a VerifyStart message. If the verification succeeds, it's the normal mode of operation. However, if there is a suspend and a resume (presumably followed by an USB reset), the verification never finishes and the device remains claimed forever. Here are some messages I have tried sending to Fprint to make it let go of the device and their respective responses, separated by a blank line: $ dbus-send --system --dest=net.reactivated.Fprint --print-reply /net/reactivated/Fprint/Device/0 net.reactivated.Fprint.Device.VerifyStop Error net.reactivated.Fprint.Error.AlreadyInUse: Device already in use by another user $ dbus-send --system --dest=net.reactivated.Fprint --print-reply /net/reactivated/Fprint/Device/0 net.reactivated.Fprint.Device.Release Error net.reactivated.Fprint.Error.AlreadyInUse: Device already in use by another user However, simply killing fprintd and restarting it fixes the "deadlock". One side effect is that I can now see what the daemon is doing. Annotated output below, my lines start with ## # fprintd Launching FprintObject ** Message: D-Bus service launched with name: net.reactivated.Fprint ** Message: entering main loop ## Locked the screen, moved the mouse cursor ** Message: user 'thewanderer' claiming the device: 0 ** Message: now monitoring fd 15 ** Message: device 0 claim status 0 ** Message: start verification device 0 finger 7 ## Swiped the finger ** Message: verify_cb: result verify-match (1) ** Message: no longer monitoring fd 15 ** Message: released device 0 ## The screen is unlocked by now ## Lock the screen again ** Message: user 'thewanderer' claiming the device: 0 ** Message: now monitoring fd 16 ** Message: device 0 claim status 0 ** Message: start verification device 0 finger 7 ## Suspend the machine by closing the lid ## Resume by opening the lid ## At this point, the USB-related message appears in syslog ## No further activity can be seen at all in output. I have tried running fprintd under strace, but the multitude of file open() calls and socket I/O did their best to obfuscate the nature of the problem. Most likely, a problem in the daemon code itself. It should at least have some kind of verification timeout and force-release for handling situations like these. I am currently in no position to try and fix fprintd (wouldn't really know where to begin), but still leaving this here if anyone wants to have a closer look at the code. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
