Package Details: systemd-lock-handler 2.4.2-1

Git Clone URL: https://aur.archlinux.org/systemd-lock-handler.git (read-only, click to copy)
Package Base: systemd-lock-handler
Description: Logind lock event to systemd target translation.
Upstream URL: https://git.sr.ht/~whynothugo/systemd-lock-handler
Keywords: lock session systemd unlock
Licenses: ISC
Submitter: whynothugo
Maintainer: whynothugo
Last Packager: whynothugo
Votes: 6
Popularity: 0.135021
First Submitted: 2017-05-29 02:18 (UTC)
Last Updated: 2023-05-04 13:01 (UTC)

Latest Comments

whynothugo commented on 2023-08-15 14:39 (UTC)

I'm not actively using this package on Arch. If somebody wants to (co)-maintain it, the help is appreciated.

OJFord commented on 2023-03-18 19:29 (UTC)

Thanks!

This could be worse tho; the service dies always after having completed all its work.

I'm not sure I follow that though - as I described this initially manifested to me as 'not locked on resume from sleep', and I've since noticed (as I added notifications on failed systemd units) that my idle hint does actually seem to be working: I get a failed systemd-lock-handler.service (and no locked screen) if I leave it unattended for a bit.

whynothugo commented on 2023-03-14 23:58 (UTC)

BTW, issue tracker is here: https://todo.sr.ht/~whynothugo/systemd-lock-handler

whynothugo commented on 2023-03-14 23:58 (UTC)

Based on these lines:

Mar 10 17:00:08 systemd-lock-handler[91599]: main.go:32: Started systemd unit: sleep.target
Mar 10 17:00:08 systemd-lock-handler[91599]: main.go:68: Failed to grab sleep inhibitor lock The operation inhibition has been requested for is already running

Looks like I tried to grab the next inhibitor too soon. Usually the second grab happens after resuming from sleep, but this one happened too quickly. Obvious this is a bug, but I'm not entirely sure how to determine when the system has come back from sleep.

This could be worse tho; the service dies always after having completed all its work.

I've updated systemd-lock-handler.service to restart on failure after 10 seconds, though that's obviously a terrible hack until a real solution is found.

OJFord commented on 2023-03-10 17:38 (UTC) (edited on 2023-03-10 17:48 (UTC) by OJFord)

@whynothugo Do you have an issue tracker for non-packaging issues?

I have an error preventing locking on sleep.target (so it sleeps unlocked), but lock.target is fine, that seems related to the 2.4 change:

Mar 10 16:59:30 systemd[1686]: Starting Logind lock event to systemd target translation...
Mar 10 16:59:30 systemd-lock-handler[91599]: main.go:160: Running for user: ojf
Mar 10 16:59:30 systemd-lock-handler[91599]: main.go:84: Listening for sleep events...
Mar 10 16:59:30 systemd-lock-handler[91599]: main.go:150: Listening for lock events...
Mar 10 16:59:30 systemd-lock-handler[91599]: main.go:165: Initialization complete.
Mar 10 16:59:30 systemd[1686]: Started Logind lock event to systemd target translation.
Mar 10 16:59:30 systemd-lock-handler[91599]: main.go:70: Got lock on sleep inhibitor
Mar 10 17:00:08 systemd-lock-handler[91599]: main.go:72: The system is going to sleep
Mar 10 17:00:08 systemd-lock-handler[91599]: main.go:32: Started systemd unit: sleep.target
Mar 10 17:00:08 systemd-lock-handler[91599]: main.go:68: Failed to grab sleep inhibitor lock The operation inhibition has been requested for is already running
Mar 10 17:00:08 systemd[1686]: systemd-lock-handler.service: Main process exited, code=exited, status=1/FAILURE
Mar 10 17:00:08 systemd[1686]: systemd-lock-handler.service: Failed with result 'exit-code'.
Mar 10 17:11:36 systemd[1686]: Starting Logind lock event to systemd target translation...
Mar 10 17:11:36 systemd-lock-handler[92642]: main.go:160: Running for user: ojf
Mar 10 17:11:36 systemd-lock-handler[92642]: main.go:84: Listening for sleep events...
Mar 10 17:11:36 systemd-lock-handler[92642]: main.go:150: Listening for lock events...
Mar 10 17:11:36 systemd-lock-handler[92642]: main.go:165: Initialization complete.
Mar 10 17:11:36 systemd[1686]: Started Logind lock event to systemd target translation.
Mar 10 17:11:36 systemd-lock-handler[92642]: main.go:70: Got lock on sleep inhibitor
Mar 10 17:11:48 systemd[1686]: Starting locking the screen...
Mar 10 17:11:48 systemd[1686]: Started locking the screen.
Mar 10 17:11:53 swaylock[93062]: pam_systemd_home(swaylock:auth): systemd-homed is not available: Unit dbus-org.freedesktop.home1.service not found.
Mar 10 17:11:53 systemd[1686]: swaylock.service: Triggering OnSuccess= dependencies.
Mar 10 17:12:18 systemd-lock-handler[92642]: main.go:140: Session signal for current user: org.freedesktop.login1.Session.Lock
Mar 10 17:12:18 systemd-lock-handler[92642]: main.go:32: Started systemd unit: lock.target
Mar 10 17:12:18 systemd[1686]: Starting locking the screen...
Mar 10 17:12:18 systemd[1686]: Started locking the screen.
Mar 10 17:12:22 swaylock[93327]: pam_systemd_home(swaylock:auth): systemd-homed is not available: Unit dbus-org.freedesktop.home1.service not found.
Mar 10 17:12:22 systemd[1686]: swaylock.service: Triggering OnSuccess= dependencies.

That's systemctl suspend at 16:59, followed by a resume (no lock-screen) and loginctl lock-session (successful, and unlocked) at 17:11.

Naively I would think if 'The operation inhibition has been requested for is already running' that's simply not an error, it just needs to catch it and carry on? Perhaps it's a symptom of something else though.

This isn't a one-off, it hasn't been working for me for some time, but I thought it related to the systemd suspend-then-hibernate regression/behaviour change in <v253, so I hadn't looked into it until now. Let me know if there's anything else I can provide (or if there's somewhere better to take this discussion/that a duplicate issue exists already).

My swaylock.service is exactly per the readme (as at v2.4.1) - except that if I change WantedBy -> RequiredBy lock.target it seems to work, or work more often, or perhaps that was a fluke - since I did have that set prior to copying the new readme (I didn't have it forking, or Restart/After/OnSuccess as added to the readme in 2.4 before).

It seems that at least part of the problem is that systemd-lock-handler.service itself doesn't restart on failure, and this seems to happen (at least) after a successful resume, which then leaves it failed & exited for the next sleep event.

ayushnix commented on 2023-02-05 05:30 (UTC)

@whynothugo looks like your key has changed for the 2.4.0 tag but it hasn't been updated in the PKGBUILD. I also can't find your key on either GitHub or Sourcehut :)

whynothugo commented on 2021-08-09 12:22 (UTC)

@alcubierre-drive Fixed. I rotated my signing key, but didn't update the one in PKGBUILD.

alcubierre-drive commented on 2021-08-09 09:33 (UTC)

I can't update; I get an invalid PGP signature error:

==> Verifying source file signatures with gpg... systemd-lock-handler git repo ... FAILED (unknown public key 388ADF1E2EEA7F1A) ==> ERROR: One or more PGP signatures could not be verified! error: failed to download sources for 'systemd-lock-handler-2.1.0-1': error: packages failed to build: systemd-lock-handler-2.1.0-1

BlubbTec commented on 2019-08-05 12:58 (UTC)

I also get this error when running:

Aug 05 14:55:15 krow systemd[1022]: Started Logind lock event to systemd target translation.
Aug 05 14:55:16 krow systemd-lock-handler[7133]: Error listening for lock events.
Aug 05 14:55:16 krow systemd-lock-handler[7133]: Traceback (most recent call last):
Aug 05 14:55:16 krow systemd-lock-handler[7133]:   File "/usr/bin/systemd-lock-handler", line 33, in main
Aug 05 14:55:16 krow systemd-lock-handler[7133]:     '/org/freedesktop/login1/session/c1',
Aug 05 14:55:16 krow systemd-lock-handler[7133]:   File "/usr/lib/python3.7/site-packages/twisted/internet/defer.py", line 654, in _runCallbacks
Aug 05 14:55:16 krow systemd-lock-handler[7133]:     current.result = callback(current.result, *args, **kw)
Aug 05 14:55:16 krow systemd-lock-handler[7133]:   File "/usr/lib/python3.7/site-packages/txdbus/client.py", line 443, in err
Aug 05 14:55:16 krow systemd-lock-handler[7133]:     'Introspection Failed: ' + e.getErrorMessage()
Aug 05 14:55:16 krow systemd-lock-handler[7133]: txdbus.error.IntrospectionFailed: Introspection Failed: org.freedesktop.DBus.Error.UnknownObject: Unknown object '/org/freedesktop/login1/session/c1'.

BlubbTec commented on 2019-08-05 12:58 (UTC)

This also requires python-service_identity as a dependency, otherwise I get:

Aug 05 14:45:48 systemd-lock-handler[6242]: :0: UserWarning: You do not have a working installation of the service_identity module: 'No module named 'service_identity''.  Please install it from <https://pypi>