search

uunicorn / open-fprintd

Fprintd replacement which allows you to have your own backend as a standalone service.
GNU General Public License v2.0
54 stars 9 forks source link

Device appears to be gone when trying to resume. #12

Open hiimdoublej opened 2 years ago

hiimdoublej commented 2 years ago

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.

linuxct commented 2 years ago

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.

l4pa commented 2 years ago

another issue opened here https://github.com/uunicorn/python-validity/issues/106

hiimdoublej commented 2 years ago

~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:

linuxct commented 2 years ago

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.

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?

ClemPera commented 2 years ago

Same here, fully updated arch

hiimdoublej commented 2 years ago

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.

godfuzz3r commented 2 years ago

Same issue here. 5.16.5-arch1-1, systemd 250 (250.3-2-arch)

linuxct commented 2 years ago

After some updates today, the fingerprint stopped working entirely for me. Did anyone else experiencing these issues also had the same fate as me?

ixnewton commented 2 years ago

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.

linuxct commented 1 year ago

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.

ixnewton commented 1 year ago

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?

ixnewton commented 1 year ago

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/

nixenos commented 1 year ago

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 :)

muesli4brekkies commented 1 year ago

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 :)

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.

ManInDark commented 10 months ago

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.

dmig commented 9 months ago

As I understand from error trace:

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.

dmig commented 9 months ago

Hm... powertop device stats show that fingerprint reader is always in use, draining battery. This definitely needs to be refactored.

nixxa commented 7 months ago

@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

alvarokrn commented 1 month ago

I'm having the same issue. Is there some ETA for this issue?

resist15 commented 2 days ago

@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

there is this service which is also diabled by default python3-validity-restart-after-resume.service you can try enabling this instead of editing open-fprintd-restart-after-resume.service