open-fprintd
open-fprintd copied to clipboard
Device appears to be gone when trying to resume.
This happens on my arch linux after I suspend and resume, open-fprintd
doesn't seems to resume.
$ systemctl status open-fprintd-resume
× open-fprintd-resume.service - Restart devices after resume
Loaded: loaded (/usr/lib/systemd/system/open-fprintd-resume.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Sun 2022-01-02 21:11:33 CST; 10s ago
Process: 3203 ExecStart=/usr/lib/open-fprintd/resume.py (code=exited, status=1/FAILURE)
Main PID: 3203 (code=exited, status=1/FAILURE)
CPU: 31ms
I tried to resume the devices manually, there's a NoSuchDevice
exception.
$ sudo /usr/lib/open-fprintd/resume.py
Traceback (most recent call last):
File "/usr/lib/open-fprintd/resume.py", line 11, in <module>
o.Resume()
File "/usr/lib/python3.10/site-packages/dbus/proxies.py", line 141, in __call__
return self._connection.call_blocking(self._named_service,
File "/usr/lib/python3.10/site-packages/dbus/connection.py", line 652, in call_blocking
reply_message = self.send_message_with_reply_and_block(
dbus.exceptions.DBusException: org.freedesktop.DBus.Python.usb.core.USBError: Traceback (most recent call last):
File "/usr/lib/python3.10/site-packages/dbus/service.py", line 715, in _message_cb
retval = candidate_method(self, *args, **keywords)
File "/usr/lib/python-validity/dbus-service", line 74, in Resume
init.open_common()
File "/usr/lib/python3.10/site-packages/validitysensor/init.py", line 29, in open_common
init_flash()
File "/usr/lib/python3.10/site-packages/validitysensor/init_flash.py", line 113, in init_flash
info = get_flash_info()
File "/usr/lib/python3.10/site-packages/validitysensor/flash.py", line 40, in get_flash_info
rsp = tls.cmd(unhex('3e'))
File "/usr/lib/python3.10/site-packages/validitysensor/tls.py", line 124, in cmd
rsp = self.usb.cmd(cmd)
File "/usr/lib/python3.10/site-packages/validitysensor/usb.py", line 102, in cmd
self.dev.write(1, out)
File "/usr/lib/python3.10/site-packages/usb/core.py", line 989, in write
return fn(
File "/usr/lib/python3.10/site-packages/usb/backend/libusb1.py", line 837, in bulk_write
return self.__write(self.lib.libusb_bulk_transfer,
File "/usr/lib/python3.10/site-packages/usb/backend/libusb1.py", line 938, in __write
_check(retval)
File "/usr/lib/python3.10/site-packages/usb/backend/libusb1.py", line 604, in _check
raise USBError(_strerror(ret), ret, _libusb_errno[ret])
usb.core.USBError: [Errno 19] No such device (it may have been disconnected)
open-fprintd
seems to be running just fine
$ sudo systemctl status open-fprintd
● open-fprintd.service - Open FPrint Daemon
Loaded: loaded (/usr/lib/systemd/system/open-fprintd.service; static)
Active: active (running) since Sun 2022-01-02 21:10:16 CST; 8min ago
Main PID: 549 (open-fprintd)
Tasks: 1 (limit: 18871)
Memory: 9.6M
CPU: 85ms
CGroup: /system.slice/open-fprintd.service
└─549 /usr/bin/python3 /usr/lib/open-fprintd/open-fprintd --debug
Jan 02 21:10:19 hiimdoublej-X1C7 open-fprintd[549]: DEBUG:root:VerifyStart
Jan 02 21:10:19 hiimdoublej-X1C7 open-fprintd[549]: DEBUG:root:VerifyFingerSelected
Jan 02 21:10:20 hiimdoublej-X1C7 open-fprintd[549]: DEBUG:root:VerifyStatus
Jan 02 21:10:22 hiimdoublej-X1C7 open-fprintd[549]: DEBUG:root:VerifyStatus
Jan 02 21:10:22 hiimdoublej-X1C7 open-fprintd[549]: DEBUG:root:VerifyStop
Jan 02 21:10:22 hiimdoublej-X1C7 open-fprintd[549]: DEBUG:root:Release
Jan 02 21:10:22 hiimdoublej-X1C7 open-fprintd[549]: DEBUG:root:do_release
Jan 02 21:11:33 hiimdoublej-X1C7 open-fprintd[549]: DEBUG:root:Suspend
Jan 02 21:11:33 hiimdoublej-X1C7 open-fprintd[549]: DEBUG:root:Resume <- This resume was triggered as usual
Jan 02 21:11:58 hiimdoublej-X1C7 open-fprintd[549]: DEBUG:root:Resume <- This resume is from manual invoke
I think something is wrong when calling dev.target.Resume()
from the manager, but I'm not too familiar with dbus so I'm not sure what's wrong here and how to fix it.
Any ideas on how to tackle this issue ? I'll happily provide any relevant logs.
Experiencing exactly this same issue right now -
root@thiccpad /home/linuxct # sudo systemctl status open-fprintd-resume
○ open-fprintd-resume.service - Restart devices after resume
Loaded: loaded (/usr/lib/systemd/system/open-fprintd-resume.service; enabled; vendor preset: disabled)
Active: inactive (dead)
Jan 09 14:30:29 thiccpad resume.py[2992]: assert_status(rsp)
Jan 09 14:30:29 thiccpad resume.py[2992]: File "/usr/lib/python3.10/site-packages/validitysensor/util.py", line 12, in assert_status
Jan 09 14:30:29 thiccpad resume.py[2992]: raise Exception('Failed: %04x' % s)
Jan 09 14:30:29 thiccpad resume.py[2992]: Exception: Failed: 0315
Jan 09 14:30:29 thiccpad systemd[1]: open-fprintd-resume.service: Main process exited, code=exited, status=1/FAILURE
Jan 09 14:30:29 thiccpad systemd[1]: open-fprintd-resume.service: Failed with result 'exit-code'.
Jan 09 14:30:29 thiccpad systemd[1]: Failed to start Restart devices after resume.
Jan 09 14:31:16 thiccpad systemd[1]: Starting Restart devices after resume...
Jan 09 14:31:17 thiccpad systemd[1]: open-fprintd-resume.service: Deactivated successfully.
Jan 09 14:31:17 thiccpad systemd[1]: Finished Restart devices after resume.
3 root@thiccpad /home/linuxct # sudo systemctl status open-fprintd-suspend
○ open-fprintd-suspend.service - Restart devices after resume
Loaded: loaded (/usr/lib/systemd/system/open-fprintd-suspend.service; enabled; vendor preset: disabled)
Active: inactive (dead)
Jan 09 14:30:29 thiccpad systemd[1]: Starting Restart devices after resume...
Jan 09 14:30:29 thiccpad systemd[1]: open-fprintd-suspend.service: Deactivated successfully.
Jan 09 14:30:29 thiccpad systemd[1]: Finished Restart devices after resume.
Jan 09 14:31:26 thiccpad systemd[1]: Starting Restart devices after resume...
Jan 09 14:31:26 thiccpad systemd[1]: open-fprintd-suspend.service: Deactivated successfully.
Jan 09 14:31:26 thiccpad systemd[1]: Finished Restart devices after resume.
open-fprintd is working fine however, as noted in OP.
3 root@thiccpad /home/linuxct # sudo systemctl status open-fprintd
● open-fprintd.service - Open FPrint Daemon
Loaded: loaded (/usr/lib/systemd/system/open-fprintd.service; static)
Active: active (running) since Sun 2022-01-09 14:26:24 CET; 10min ago
Main PID: 1206 (open-fprintd)
Tasks: 1 (limit: 38386)
Memory: 9.3M
CPU: 73ms
CGroup: /system.slice/open-fprintd.service
└─1206 /usr/bin/python3 /usr/lib/open-fprintd/open-fprintd --debug
Jan 09 14:26:38 thiccpad open-fprintd[1206]: DEBUG:root:VerifyStart
Jan 09 14:26:38 thiccpad open-fprintd[1206]: DEBUG:root:VerifyFingerSelected
Jan 09 14:26:40 thiccpad open-fprintd[1206]: DEBUG:root:VerifyStatus
Jan 09 14:26:40 thiccpad open-fprintd[1206]: DEBUG:root:VerifyStop
Jan 09 14:26:40 thiccpad open-fprintd[1206]: DEBUG:root:Release
Jan 09 14:26:40 thiccpad open-fprintd[1206]: DEBUG:root:do_release
Jan 09 14:30:29 thiccpad open-fprintd[1206]: DEBUG:root:Suspend
Jan 09 14:30:29 thiccpad open-fprintd[1206]: DEBUG:root:Resume
Jan 09 14:31:17 thiccpad open-fprintd[1206]: DEBUG:root:Resume
Jan 09 14:31:26 thiccpad open-fprintd[1206]: DEBUG:root:Suspend
I will also gladly provide logs as needed.
another issue opened here https://github.com/uunicorn/python-validity/issues/106
~This issue seems to have gone away after my system upgrade today. It did upgrade the systemd
to 250.2-2
. Wonder if that's the difference tho. Maybe @linuxct @l4pa can try upgrading and see if it helps. The maintainer can decide to close this issue or wait for other responses I guess.~
It wasn't fixed, see my comment :point_down:
This issue seems to have gone away after my system upgrade today. It did upgrade the
systemd
to250.2-2
. Wonder if that's the difference tho. Maybe @linuxct @l4pa can try upgrading and see if it helps. The maintainer can decide to close this issue or wait for other responses I guess.
I believe I was already on systemd 250.2-2 when I posted my comment, but for the sake of it I reinstalled it and tried to re-enable the services, it did not solve the issue. I also upgraded all my installed packages to their latest versions. Any idea of anything else you did to try to fix it?
Same here, fully updated arch
I stand corrected, it did not fix my original issue. I still couldn't use fprintd resuming. The case where I thought it was fixed, my device didn't actually suspend, it only locked the screen.
Same issue here. 5.16.5-arch1-1
, systemd 250 (250.3-2-arch)
After some updates today, the fingerprint stopped working entirely for me. Did anyone else experiencing these issues also had the same fate as me?
I found that if I add a "systemctl stop python3-validity" and then start at suspend/resume fprint works again on resume. Using a script to manage suspend resume actions: /usr/lib/systemd/system-sleep/suspend.sh
#!/bin/sh
#
# This script should prevent suspend errors
#
if [ "${1}" == "pre" ]; then
# Do the thing you want before suspend here:
systemctl stop python3-validity
elif [ "${1}" == "post" ]; then
# Do the thing you want after resume here:
systemctl restart python3-validity
fi
I'm using open-fprintd which uses open-fprintd-suspend open-fprintd-resume which are meant to manage suspend/resume but the above script seems to avoid problems with resume.
I found that if I add a "systemctl stop python3-validity" and then start at suspend/resume fprint works again on resume. Using a script to manage suspend resume actions: /usr/lib/systemd/system-sleep/suspend.sh
#!/bin/sh # # This script should prevent suspend errors # if [ "${1}" == "pre" ]; then # Do the thing you want before suspend here: systemctl stop python3-validity elif [ "${1}" == "post" ]; then # Do the thing you want after resume here: systemctl restart python3-validity fi
I'm using open-fprintd which uses open-fprintd-suspend open-fprintd-resume which are meant to manage suspend/resume but the above script seems to avoid problems with resume.
Sadly this still didn't do the trick for me. Same config as my previous messages in this same thread. Stopping and restarting the service did not help bringing up the fingerprint reader after the device has gone to sleep once, even when open-fprintd-{suspend,resume} are enabled. As a matter of fact, messing around with stopping and starting the services without sending the device to sleep causes the fingerprint to stop working as well, i.e., the fingerprint only works after a fresh boot and as long as the services live. Messing around with them makes the whole thing to stop working.
Check dmesg for problems going into suspend and then resume for open-fprint-suspend then open-fprint-resume? I get: [13045.255819] audit: type=1130 audit(1672596601.574:286): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=open-fprintd-suspend comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' [13045.255826] audit: type=1131 audit(1672596601.574:287): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=open-fprintd-suspend comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' [13045.364294] Freezing user space processes ... (elapsed 0.001 seconds) done. Then: [16974.580473] audit: type=1130 audit(1672600529.990:290): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=open-fprintd-resume comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' [16974.580490] audit: type=1131 audit(1672600529.990:291): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=open-fprintd-resume comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Since you mention it, I used this work around for python3-validity up till now. It may be significant, but now I have kernel 6.1 (6.1.1-1-MANJARO) and commenting out the lines in suspend.sh makes no difference i.e. it still works. With 6.0 I still needed the work-around. Try more recent kernels?
For your information I followed the install procedure from here some time ago in this thread. Your hardware and sensor may affect successful operation. Fedora should have the same packages as Arch? https://www.reddit.com/r/thinkpad/comments/ibcpob/fingerprint_works_on_t480_kernel_581/
I've replaced the /usr/lib/open-fprintd/resume.py
in open-fprintd-resume.service
with following shell script:
#!/bin/sh
/bin/systemctl restart python3-validity && sleep 5 && /usr/lib/open-fprintd/resume.py
and now it seems like my sensor is working correctly on Gentoo with genkernel 6.1 and latest available versions of python3-validity and open-fprintd I hope it might be of use to someone :)
I've replaced the
/usr/lib/open-fprintd/resume.py
inopen-fprintd-resume.service
with following shell script:#!/bin/sh /bin/systemctl restart python3-validity && sleep 5 && /usr/lib/open-fprintd/resume.py
and now it seems like my sensor is working correctly on Gentoo with genkernel 6.1 and latest available versions of python3-validity and open-fprintd I hope it might be of use to someone :)
Awesome! Many thanks for this little fix.
Ps- I don't need the sleep on my Thinkpad X270 with the validity 138a:0097.
e - Aha it broke again, but seems to work with a sleep 1. I suppose it'll depend on how quick your PC can restart python3-validity.
I couldn't get it to work with the solution of editing open-fprintd-resume service, so I just removed the o.Suspend()
and o.Resume()
from the /usr/lib/open-fprintd
suspend.py
and resume.py
files respectively, which appeared to fix the issue.
As I understand from error trace:
- suspended reader disappears from system
-
Usb.dev
in python-validity/validitysensor/usb.py keeps handle to previously open device, which becomes broken after resume and causes exceptionusb.core.USBError: [Errno 19] No such device (it may have been disconnected)
Solution here would be to close device on suspend and find/reopen on resume. Also, I'd probably also add a udev trigger for device resume instead of on-resume service.
Hm... powertop
device stats show that fingerprint reader is always in use, draining battery. This definitely needs to be refactored.
@nixenos I slightly modified your script to make it work on my system:
[Service]
Type=oneshot
#ExecStart=/usr/lib/open-fprintd/resume.py
ExecStart=/usr/bin/systemctl restart python3-validity open-fprintd && sleep 2 && /usr/lib/open-fprintd/resume.py
As journalctl -e
showed me, after laptop has resumed it had lost connection to USB device (fingerprint reader):
... 13:12:20 fedora open-fprintd[60527]: DEBUG:root:Resume
... 13:12:20 fedora dbus-service[60636]: DEBUG:root:In Resume
... 13:12:20 fedora dbus-service[60636]: DEBUG:root:>cmd> 3e
... 13:12:20 fedora dbus-service[60636]: DEBUG:root:>cmd> 3e
... 13:12:20 fedora python3[61192]: detected unhandled Python exception in '/usr/lib/open-fprintd/resume.py'
[ skipped ]
... 13:12:20 fedora resume.py[61192]: usb.core.USBError: [Errno 19] No such device (it may have been disconnected)
... 13:12:20 fedora resume.py[61192]: During handling of the above exception, another exception occurred:
Also, restarting only python3-validity
wasn't enough for me, has to be restarted both services, open-fprintd
and python3-validity
.
BTW, open-fprintd service comes with open-fprintd-restart-after-resume.service
that is disabled by default. So, instead of editing open-fprintd-resume.service
, the restart-after-resume service can be enabled. In my case it contains:
[Service]
Type=simple
ExecStart=/bin/systemctl --no-block restart open-fprintd.service
and requires a small modification:
ExecStart=/bin/systemctl --no-block restart open-fprintd.service python3-validity.service
Laptop: Lenovo Thinkpad X1 Extreme Gen 2 OS: Fedora 40
I'm having the same issue. Is there some ETA for this issue?