fprintd sometimes stops working. This happens very infrequently. From the
moment it happens, the fingerprint reader won't be activated any more for
unlocking the screen / logging in, and passwords have to be entered again.

Since it happens very infrequently, I don't have much more information, except
perhaps this line from /var/log/messages (though I'm not sure it occurred at
the time fprintd stopped working):

=====
Apr 22 11:42:56 boulez kernel: [924858.156498] usb 1-1.3: usbfs: process 6247
(fprintd) did not claim interface 0 before use
=====

When the problem occurs again, I will check if this message gets logged again.

Arnaud

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.