Waking up from suspend

[uunicorn]

Waking up from suspend

[uunicorn]

Sorry I've disappeared for a month.
I've just pushed the changes I mentioned above to open-fprintd and python-validity projects.
It is quite hacky but seems to be working fine at least with Gnome:
Whenever you resume from sleep and press any key immediately, Gnome will display a password prompt.
Once the sensor initialization is complete, it will automatically start the verification session and show the (or swipe finger) message in the dialog.

[kakawait]

For me issue is resolved but I'm not author of the issue

[uunicorn]

The current proposed working solution risks bricking the chip due to excessive restarts and we need to find better one.

Um.. If you're talking about python3-validity-suspend-restart.service, it does not cause the chip to restart, only the service.
Furthermore, I don't think chip restarts (unlike factory resets) can eventually brick the chip.

[peterbabic]

The current proposed working solution risks bricking the chip due to excessive restarts and we need to find better one.

Um.. If you're talking about python3-validity-suspend-restart.service, it does not cause the chip to restart, only the service.
Furthermore, I don't think chip restarts (unlike factory resets) can eventually brick the chip.

I am referring to #3 (comment)

• maybe I did read it wrong. What can anyone of us do to help, please?

[uunicorn]

Ah, yes. I was talking about a hypothetical situation when we have a Restart=always service and some sort of unknown error which is causing the service to restart indefinitely. In the end I've adopted the workaround suggested by @flops . I.e.

1. systemd will never attempt to automatically restart the service even if it died unexpectedly due to an error
2. if the error was caused by a sensor reboot, udev rule will start the service when the sensor is reconnected (this happens a few times as part of a normal pairing process)
3. when your laptop does to sleep, the sensor is powered off, however it does not cause the usb device to reconnect on resume. So, we have another systemd service (python3-validity-suspend-restart.service) which is triggered by a suspend event and restarts the main service so that it can re-establish the TLS session

This is how it is intended to work anyway.

After waking up from suspend, I need to run systemctl restart python3-validity to make the fingerprint reader work again.

I assume it is not working for you for some reason. Which version are you running?
Do you have python3-validity-suspend-restart.service as well?

[peterbabic]

@uunicorn yes I do, it is inactive (dead) right now. Should I enable it? I have not read anything about it so far.

[uunicorn]

It should be enabled, but inactive (dead) most of the time. The whole purpose of this service is to run systemctl restart python3-validity on suspend (hibernate, etc) and go back to inactive state.

Can you provide some logs for both python3-validity-suspend-restart.service and python3-validity.service to see what's going on when you suspend/resume?

[kakawait]

I don't know if same issue, but after suspend/resume fingerprint is not working directly. I've to wait few seconds (~30 sec).

I've checked both services are enable and running.

Here logs from both

python3-validity.log
python3-validity-suspend-restart.log

I'm suspecting that

Sep 15 12:04:24 archi python3[1197]: DEBUG:root:Manager is back online, registering
Sep 15 12:04:40 archi python3[1197]: DEBUG:root:In ListEnrolledFingers thibaud

corresponding to the few seconds I talked before.

I'd like to try #3 (comment) driver but no yet tested (I'm looking for install instruction atm :))

[uunicorn]

I don't know if same issue, but after suspend/resume fingerprint is not working directly. I've to wait few seconds (~30 sec).

Yes, it looks like a different issue. I think I'm having this one as well. When I:

1. open the lid,
2. don't touch anything and wait for ~5 seconds,
3. press any key

Then it always offers me to use a finger to unlock the session.

However when I:

1. open the lid,
2. press something immediately

Then sometimes it does not offer me the choice to use my finger.

If this is a kind of problem you are having, then I probably know what's causing it. It has nothing to do with hardware, but rather how python-validity currently registers with open-fprintd. When computer resumed, the python-validity service is restarted. It takes a few seconds to initialize the device. During this time there are no devices registered with open-fprintd. So clients are under impression that there are no supported devices.

To fix this problem python-validity needs to register with open-fprintd as soon as possible, without waiting for device initialization to finish. I'll try to test this theory tonight.

[uunicorn]

I've tested this theory. It is indeed a race condition. However solution proposed above won't work. Gnome screen lock may try to access the device even before python3-validity-suspend-restart.service kicks in. So, python-validity needs some other way to detect a device state.

Re libfprint approach: instead of keeping the device always open to minimize the setup time, libfprint opens and initializes a device before each operation. So you will have the same few seconds delay, but before each operation, not just the first one after resume.

[kakawait]

@uunicorn thank you for feedback

Maybe if I disable & stop python3-validity-suspend-restart.service that could work? I'll test.

Re libfprint approach: instead of keeping the device always open to minimize the setup time, libfprint opens and initializes a device before each operation. So you will have the same few seconds delay, but before each operation, not just the first one after resume.

Correct me, but open-fprintd replace fprintd but both depends on libfprint?

[uunicorn]

Maybe if I disable & stop python3-validity-suspend-restart.service that could work? I'll test.

I don't think it will work. When you suspend your computer, it powers off the sensor and this effectively terminates the TLS session on one end without letting the other end know. When you resume, the USB device descriptor is still alive, but python-validity has no idea that suspend + resume has just happened. So, the next TLS packet it sends will cause an error, since from the device point of view TLS session was never established after power on. The whole point of having python3-validity-suspend-restart.service was to restart the python-validity and re-initialize the TLS session. Unfortunately this approach is not always fast enough.

We probably need to find a way to get notified before we go to sleep, so that we have a chance to initialize the TLS state before the device will be used again.

Correct me, but open-fprintd replace fprintd but both depends on libfprint?

No, open-fprintd does not depend on libfprint. open-fprintd is just a simple DBus broker written in Python. The idea behind it is to provide a loose coupling between the clients (PAM module, Gnome settings, etc) and the backend drivers (python-validity). In theory it is possible to write a backend driver linked against libfprint which will register itself with open-fprintd and provide compatibility for all devices supported by libfprint. But at the moment nothing in open-fprintd stack depends on libfprintd.

[kakawait]

No, open-fprintd does not depend on libfprint. open-fprintd is just a simple DBus broker written in Python. The idea behind it is to provide a loose coupling between the clients (PAM module, Gnome settings, etc) and the backend drivers (python-validity). In theory it is possible to write a backend driver linked against libfprint which will register itself with open-fprintd and provide compatibility for all devices supported by libfprint. But at the moment nothing in open-fprintd stack depends on libfprintd.

Sorry for my ignorance 🙈

I though because when I've checked aur dependencies we can see that is depending on fprintd-clients that is depending on libfprint

We probably need to find a way to get notified before we go to sleep, so that we have a chance to initialize the TLS state before the device will be used again.

isn't the goal of systemd unit?

Before=sleep.target
Before=suspend.target
...
WantedBy=sleep.target
WantedBy=suspend.target

[uunicorn]

fprintd-clients that is depending on libfprint

I'm pretty sure that was not the intention. I do not maintain AUR packages, only DEBs, so I'm not quite sure why it is this way. My guess is that AUR package inherited deps from the upstream fprintd.

isn't the goal of systemd unit?

Correct, and this is exactly what python3-validity-suspend-restart.service approach relies on. Unfortunatelly it is simply not fast enough. Units like that actually executed after resume. AFAIK, it is impossible to have a userspace hook which is guaranteed to finish before the process ends up in a freezer (unlike the kernel drivers). There must be some other way to detect that there was a suspend/resume without introducing a race condition.

[uunicorn]

AFAIK, it is impossible to have a userspace hook which is guaranteed to finish before the process ends up in a freezer (unlike the kernel drivers).

Nope, this is not true. In fact, a systemd service with Type=oneshot can do the trick. It can use the DBus to synchronously notify python-validity that the system is going to sleep/wake up, so that all client requests could be delayed until the device is ready.

I'll try to test this approach over the weekend.

[kakawait]

I'll try to test this approach over the weekend.

I could help to test if you want.

[kakawait]

As soon AUR package is fixed (https://aur.archlinux.org/packages/python-validity-git/#comment-770877) I'll give a try

[kakawait]

Finally I packaged locally new versions (python-validity & open-fprintd) and after enabling every new systemd unit from open-fprintd... 🥁

It work like a charm with i3lock + i3

@uunicorn I think you should release both python-validity & open-fprintd version in github to allow AUR owner to move on new version

[ahbnr]

EDIT: Ignore the following. This was an error on my part, see #39 (comment)

---

Hi! I installed the python-validity-git package by modifying the PKGBUILD so that it no longer tries to remove the service file python3-validity-suspend-restart.service.

Sadly, I still experience python-validity being broken after a suspend (TLS session seems to be gone).

I manually installed python3-validity-suspend-restart.service again in /etc/systemd/system and enabled it, and now the issue is gone. So it seems the restart service is still needed for some systems.

I didn't try to understand the inner workings of python-validity yet, but could it be, that the new session restart methods of commit 92eab67 are only called by some screen locks (e.g. GNOME)?
In my case, I have no desktop environment like GNOME (only i3 WM + slock for locking and systemd suspend for suspending) so probably none of my system components triggers the new session restart methods.

One workaround could be, to give users instructions on how to reinstall the removed systemd restart service manually, like i did.
So here are the detailed instructions for Arch Linux for the newest git version of python-validity:

1. Create a new file python3-validity-suspend-restart.service in /etc/systemd/system
2. Put the following content into the file:

[Unit]
Description=Restart python-validity after resume
After=suspend.target hibernate.target hybrid-sleep.target suspend-then-hibernate.target

[Service]
Type=simple
ExecStart=/bin/systemctl --no-block restart python3-validity.service

[Install]
WantedBy=suspend.target hibernate.target hybrid-sleep.target suspend-then-hibernate.target

(thats the exact content of the service file before it got removed: https://github.com/uunicorn/python-validity/blob/df3f80210424fe7005fa7ff33bd4bdf88e4c8e92/debian/python3-validity-suspend-restart.service)

3. Enable the service:

systemctl enable python3-validity-suspend-restart

[uunicorn]

Sadly, I still experience python-validity being broken after a suspend (TLS session seems to be gone).

The fix I mentioned above have two parts: in python-validity and in open-fprintd. In fact, open-fprintd if where the most of the changes are this time. Ubuntu packages for open-fprintd now contain three additional systemd service definitions (one for dbus service itself and two additional one-shot services which are used to synchronously notify all the drivers about system suspend/resume transitions).

Could it be that you have upgraded python-validity without installing the latest open-fprintd?

[ahbnr]

Sadly, I still experience python-validity being broken after a suspend (TLS session seems to be gone).

The fix I mentioned above have two parts: in python-validity and in open-fprintd. In fact, open-fprintd if where the most of the changes are this time. Ubuntu packages for open-fprintd now contain three additional systemd service definitions (one for dbus service itself and two additional one-shot services which are used to synchronously notify all the drivers about system suspend/resume transitions).

Could it be that you have upgraded python-validity without installing the latest open-fprintd?

Thank you for your quick reply. I have the newest version of open-fprintd available on AUR installed, which is 0.6-1.
I guess, I have to create a git AUR package for open-fprintd to get the latest commits. I will try that on wednesday (I don't know if I will have time today or tomorrow).

[ahbnr]

I guess, I have to create a git AUR package for open-fprintd to get the latest commits. I will try that on wednesday (I don't know if I will have time today or tomorrow).

nvm, looking at the commit history, it seems version 0.6 of open-fprintd should include the relevant commit.

Can I supply you with any log information that could help resolve this issue?

[kakawait]

I confirm both aur python-validity and open-fprintd (non git) are up to date. I'm using it and is working like a charm

[peterbabic]

Great work!

$ yay -Q | grep -e open-fprintd -e python-validity
open-fprintd 0.6-1
python-validity 0.12-1

However, I have updated both today as well and tested twice, but I do not see any changes whatsoever. After waking up from suspend I still need to manually # systemctl restart python3-validity.service to be able ot use the fingerprint reader again. What can I do to debug further, please?

[uunicorn]

What can I do to debug further, please?

Can you check the output from systemctl status for open-fprintd-suspend.service, open-fprintd-resume.service and open-fprintd.service.

[peterbabic]

@uunicorn The open-fprintd-resume and open-fprintd-suspend were not enabled. After enabling and starting them both, nothing worked (sudo did not ask for password prompt nor finger swipe).

After restart however, the swipe worked. Then after suspend, the swipe was accepted again. Thank You!

[ahbnr]

@uunicorn The open-fprintd-resume and open-fprintd-suspend were not enabled. After enabling and starting them both, nothing worked (sudo did not ask for password prompt nor finger swipe).

I'm sorry for worrying you, @uunicorn . I too didn't correctly enable both of the first two services. Everything seems to work perfectly now.
I should have very carefully read and reiterated all instructions.

[hasmar04]

May I suggest this be put in the readme? These instructions are probably very useful to most people who install this.