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

hiimdoublej · 2022-01-02T13:26:05Z

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.

The text was updated successfully, but these errors were encountered:

linuxct · 2022-01-09T13:40:27Z

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 · 2022-01-12T20:39:22Z

another issue opened here uunicorn/python-validity#106

hiimdoublej · 2022-01-15T16:30:18Z

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 👇

linuxct · 2022-01-17T08:45:31Z

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 · 2022-01-18T13:27:56Z

Same here, fully updated arch

hiimdoublej · 2022-01-22T02:28:05Z

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 · 2022-02-09T12:06:16Z

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

linuxct · 2022-02-22T20:53:54Z

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 · 2022-11-20T00:52:32Z

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 · 2023-01-01T18:08:38Z

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 · 2023-01-01T19:46:00Z

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 · 2023-01-01T20:05:26Z

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 · 2023-03-12T23:03:03Z

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 · 2023-04-07T18:42:20Z

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 · 2024-01-11T12:37:25Z

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 · 2024-02-28T13:59:40Z

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 exception usb.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.

dmig · 2024-02-28T17:24:49Z

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

nixxa · 2024-05-01T11:40:56Z

@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 · 2024-10-10T12:57:53Z

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

resist15 · 2024-11-29T11:35:50Z

@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

l4pa mentioned this issue Jan 12, 2022

Strange issue with open-fprintd-resume.service #10

Open

pendula95 mentioned this issue Aug 22, 2022

Fix for "Fingerprint not working after waking up from suspend" doesn't work on Fedora 36 uunicorn/python-validity#127

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

hiimdoublej commented Jan 2, 2022

linuxct commented Jan 9, 2022

l4pa commented Jan 12, 2022

hiimdoublej commented Jan 15, 2022 •

edited

Loading

linuxct commented Jan 17, 2022 •

edited

Loading

ClemPera commented Jan 18, 2022

hiimdoublej commented Jan 22, 2022

godfuzz3r commented Feb 9, 2022 •

edited

Loading

linuxct commented Feb 22, 2022

ixnewton commented Nov 20, 2022 •

edited

Loading

linuxct commented Jan 1, 2023

ixnewton commented Jan 1, 2023

ixnewton commented Jan 1, 2023

nixenos commented Mar 12, 2023

muesli4brekkies commented Apr 7, 2023 •

edited

Loading

ManInDark commented Jan 11, 2024 •

edited

Loading

dmig commented Feb 28, 2024

dmig commented Feb 28, 2024

nixxa commented May 1, 2024 •

edited

Loading

alvarokrn commented Oct 10, 2024

resist15 commented Nov 29, 2024 •

edited

Loading

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

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

Comments

hiimdoublej commented Jan 2, 2022

linuxct commented Jan 9, 2022

l4pa commented Jan 12, 2022

hiimdoublej commented Jan 15, 2022 • edited Loading

linuxct commented Jan 17, 2022 • edited Loading

ClemPera commented Jan 18, 2022

hiimdoublej commented Jan 22, 2022

godfuzz3r commented Feb 9, 2022 • edited Loading

linuxct commented Feb 22, 2022

ixnewton commented Nov 20, 2022 • edited Loading

linuxct commented Jan 1, 2023

ixnewton commented Jan 1, 2023

ixnewton commented Jan 1, 2023

nixenos commented Mar 12, 2023

muesli4brekkies commented Apr 7, 2023 • edited Loading

ManInDark commented Jan 11, 2024 • edited Loading

dmig commented Feb 28, 2024

dmig commented Feb 28, 2024

nixxa commented May 1, 2024 • edited Loading

alvarokrn commented Oct 10, 2024

resist15 commented Nov 29, 2024 • edited Loading

hiimdoublej commented Jan 15, 2022 •

edited

Loading

linuxct commented Jan 17, 2022 •

edited

Loading

godfuzz3r commented Feb 9, 2022 •

edited

Loading

ixnewton commented Nov 20, 2022 •

edited

Loading

muesli4brekkies commented Apr 7, 2023 •

edited

Loading

ManInDark commented Jan 11, 2024 •

edited

Loading

nixxa commented May 1, 2024 •

edited

Loading

resist15 commented Nov 29, 2024 •

edited

Loading