Screen Lock Sensor Not Functioning

[sqshr]

Hello
As far as I can tell, the screen lock sensor doesn't seem to be functioning, all is set up and working otherwise.

Installed from go-hass-agent-5.1.0-1-x86_64.pkg.tar.zst (onto arch)

I've seen where the code for the screen lock is and grepped through the debug output for "lock", which should hit any strings, and I don't see any errors nor the sensor appear in home assistant (when many others do).

I'm not running a DE, just awesome with xscreensaver, but I've looked and definitely have org.freedesktop.ScreenSaver as a service, so I don't think it's on my end (very happy to be proven wrong though).

[joshuar]

Hey @sqshr that is no good. Would you be able to run the following in a terminal:

dbus-monitor "type='signal',sender='org.freedesktop.ScreenSaver',interface='org.freedesktop.ScreenSaver',path='/org/freedesktop/ScreenSaver',member='ActiveChanged'"

This will monitor for the signals that the sensor relies upon.

While the above command is running, can you try locking and unlocking your screen?

When you come back to your unlocked desktop and the terminal, can you check for output from the command that looks like:

signal time=1699659402.579842 sender=:1.27 -> destination=(null destination) serial=613 path=/org/freedesktop/ScreenSaver; interface=org.freedesktop.ScreenSaver; member=ActiveChanged
   boolean true
signal time=1699659408.333489 sender=:1.27 -> destination=(null destination) serial=615 path=/org/freedesktop/ScreenSaver; interface=org.freedesktop.ScreenSaver; member=ActiveChanged
   boolean false

The above shows the screen lock going on and off and these are the signals the agent is watching for. If we don't see those, then it's possible that your setup isn't exposing screen lock state via that service, if you do see those signals, then definitely there is a bug in the code.

[sqshr]

Hi,
I did wonder if this might be the issue, but wasn't 100% certain how to check. So I'm not seeing those messages on lock/unlock, only:

   string ":1.1006"
signal time=1699868295.177227 sender=org.freedesktop.DBus -> destination=:1.1006 serial=4 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameLost
   string ":1.1006"

I've tried gnome-screensaver too (as I assumed that would send the signals) but apparently not!

Running dbus-monitor --session "type='signal',interface='org.gnome.ScreenSaver'" with gnome-screensaver shows the appropriate output.

Looking under /org/freedesktop/ScreenSaver, I only see Inhibit and Uninhibit as methods- I assume there should be more?

Sorry for opening a bug when the issue is clearly me! I'll try and work out what I'm missing. Thanks for your help :)

[joshuar]

Hey this is interesting. It seems like there are multiple places that expose screen locking status on D-Bus. I wonder if there is a better place for me to monitor that covers more desktops/window managers.

Can you see if you get any output calling the following method with dbus-send:

dbus-send --system  --print-reply --dest=org.freedesktop.login1 /org/freedesktop/login1 org.freedesktop.login1.Manager.ListSessions

There should hopefully be an object path in the output, which looks something like: /org/freedesktop/login1/session/_33.

Can you copy that path and then run the following:

dbus-monitor --system "type='signal',interface='org.freedesktop.DBus.Properties',path='/org/freedesktop/login1/session/_33',member='PropertiesChanged'"

Replacing the path as appropriate.

Then if you lock and unlock your screen, do you see any signals output in the terminal?

🤞 that there are signals exposed there by Awesome. If so, I could change the code to monitor this location. I seem to get signals reporting in the above for my KDE desktop. I'm assuming Gnome probably does the same. If Awesome also does, then it might be that this is a good place to monitor and catch screen-locking on more machines.

[sqshr]

Hey.
Sadly no joy. I have a session number, but there's no output there either. I have tried amending my rc.lua (awesome config file) to even register the org.freedesktop.ScreenSaver path, in case that causes logging, but no (I've been trying xscreensaver and gnome-screensaver).

I have noted that systemd login status is respected- so if I run loginctl lock-session, my session gets locked. There must be something in dbus somewhere?!

Casting the net wide (dbus-monitor --session 2>&1 | grep -i lock ), there was nothing in the session bus, so I figured I'd try system:

signal time=1699951679.617107 sender=:1.4 -> destination=(null destination) serial=771 path=/org/freedesktop/login1/session/_32; interface=org.freedesktop.login1.Session; member=Lock

So there's the lock signal- I don't see an unlock one though! Again tried with both xscreensaver and gnome-screensaver.

[joshuar]

Interesting! It seems like it might be more useful to use the signal emitted under /org/freedesktop/login1 than /org/freedesktop/ScreenSaver, as that might catch more environments. It seems to work for me on KDE, so assuming Gnome is the same, and hopefully some others... I see that when I use loginctl lock-session I get the signals. I'll implement this in an upcoming patch (it's in the code now).

It's definitely odd that you only see the lock signal and not an unlock one. Did you get any further with your troubleshooting?

[sqshr]

Troubleshooting is perhaps a generous term, but I have a horrendous workaround in bash:

xscreensaver-command --watch| while read line; do echo $line | grep UNBLANK && loginctl unlock-session; done

This will generate the unlock message every time the screen is unlocked (I'll just throw it in ~/.xinitrc). Amusingly, this is referenced in the xscreensaver man page as the way to do things like this: https://www.jwz.org/xscreensaver/man3.html except their example is in perl (ick).

So as long as my screen lock key combination runs loginctl lock-session and the above script is running- I get the lock and unlock signals on a manual lock (ignoring screen blank timeouts for now).

[joshuar]

Hey I've released version 5.1.2 which contains the changed code to get screen lock status as discussed in this issue. I'm hoping that works, together with your own workaround above for you. Thanks for helping here!

[sqshr]

Hi, thanks very much- I was on holiday last week, so I'm about to give it a go!

[joshuar]

Hey @sqshr, did you get a chance to try out the new version? I'd go with the latest v6.0.1 as well which has the same fix but also more other fixes :)

[sqshr]

Hi,
My apologies, things have been a bit manic- I've just tried the latest version and it seems to crash when I run loginctl lock-session

panic: runtime error: index out of range [1] with length 0

goroutine 72 [running]:
github.com/joshuar/go-hass-agent/internal/linux.BatteryUpdater.func1(0xc0002acfa8?)
	/home/runner/work/go-hass-agent/go-hass-agent/internal/linux/batterySensor.go:322 +0x334
github.com/joshuar/go-hass-agent/pkg/dbushelpers.(*busRequest).AddWatch.func1()
	/home/runner/work/go-hass-agent/go-hass-agent/pkg/dbushelpers/dbus.go:203 +0x8f
created by github.com/joshuar/go-hass-agent/pkg/dbushelpers.(*busRequest).AddWatch in goroutine 36
	/home/runner/work/go-hass-agent/go-hass-agent/pkg/dbushelpers/dbus.go:194 +0x145

I've also run it and not locked my screen- in that case it seems to sit happily/stably. Let me know any other output you'd like to help!

[joshuar]

I can see what the problem is here. I recently discovered that when you add D-Bus watches, all watches get all data from every other watch. I was expecting a particular watch to only receive the data it was watching for. The battery sensor code was written this way. I've fixed it up and v6.0.2 should resolve this problem.

Can you try it out?

[sqshr]

Good news- It's stable when I lock and unlock now! However: I'm not seeing any debug output for locking/unlocking (I've grepped for 'lock' and also 'session'. I've also looked in home assistant and can't see lock state as a sensor.

Just to confirm, other sensors are updating- so it's all registered and working otherwise. Debug output follows:

3:56PM DBG Debug logging enabled.
3:56PM DBG Running UpgradeConfig.
3:56PM WRN No UI. Will not display tray icon.
3:56PM DBG Registration status is true
3:56PM WRN No UI. Likely running headless. Not running Fyne UI loop.
3:56PM DBG Running ValidateConfig.
3:56PM DBG Could not export secret. error="key hass.secret not set"
3:56PM WRN Running headless, will not register for receiving notifications.
3:56PM DBG Could not find any script files.
3:56PM WRN Unsupported or unknown portal. App sensors will not run.
3:56PM WRN Unable to retrieve property org.freedesktop.NetworkManager.ActiveConnections (org.freedesktop.NetworkManager) error="The name org.freedesktop.NetworkManager was not provided by any .service files"
3:56PM WRN Could not retrieve active connection list. error="The name org.freedesktop.NetworkManager was not provided by any .service files"
3:56PM WRN Unable to retrieve property net.hadess.PowerProfiles.ActiveProfile (net.hadess.PowerProfiles) error="The name net.hadess.PowerProfiles was not provided by any .service files"
3:56PM DBG Cannot retrieve a power profile from D-Bus. Will not run power sensor. error="The name net.hadess.PowerProfiles was not provided by any .service files"
3:56PM WRN Unable to execute org.freedesktop.problems.GetProblems on org.freedesktop.problems (args: []) error="The name org.freedesktop.problems was not provided by any .service files"
3:56PM DBG Listening for sensor updates.
3:56PM WRN Could not fetch temperatures. error="Number of warnings: 2"
3:56PM DBG Tracking location with geoclue.
3:56PM DBG Sensor updated. id=AC_battery_state name=" Battery State" state=unknown
3:56PM DBG Sensor updated. id=bytes_received name="Bytes Received" state="21280995407 B"
3:56PM DBG Sensor updated. id=uptime name=Uptime state="510.4938888888889 h"
3:56PM DBG Sensor updated. id=memory_total name="Memory Total" state="33365569536 B"
3:56PM DBG Sensor updated. id=cpu_load_average_(1_min) name="CPU load average (1 min)" state="0.35 load"
3:56PM DBG Sensor updated. id=kernel_version name="Kernel Version" state=6.5.9-arch2-1
3:56PM DBG Sensor updated. id=current_users name="Current Users" state="1 users"
3:56PM DBG Sensor updated. id=mountpoint_root name="Mountpoint / Usage" state="67.5 %"
3:56PM DBG Sensor updated. id=power_state name="Power State" state="Powered On"
3:56PM DBG Sensor updated. id=AC_battery_level name=" Battery Level" state=unknown
3:56PM DBG Sensor updated. id=temp_acpitz name="Acpitz Temp" state="44 °C"
3:56PM DBG Sensor updated. id=bytes_sent name="Bytes Sent" state="9892378063 B"
3:56PM DBG Sensor updated. id=last_reboot name="Last Reboot" state=2023-11-27T09:26:25Z
3:56PM DBG Sensor updated. id=memory_available name="Memory Available" state="24889507840 B"
3:56PM DBG Sensor updated. id=cpu_load_average_(5_min) name="CPU load average (5 min)" state="0.49 load"
3:56PM DBG Sensor updated. id=distribution_name name="Distribution Name" state=Arch
3:56PM DBG Sensor updated. id=mountpoint_.snapshots name="Mountpoint /.snapshots Usage" state="67.5 %"
3:56PM DBG Sensor updated. id=BAT0_battery_state name="5B10W51826 Battery State" state=unknown
3:56PM DBG Sensor updated. id=temp_nvme_composite name="Nvme Composite Temp" state="44.85 °C"
3:56PM DBG Sensor updated. id=bytes_received_throughput name="Bytes Received Throughput" state="<nil> B/s"
3:56PM DBG Sensor updated. id=memory_used name="Memory Used" state="6925303808 B"
3:56PM DBG Sensor updated. id=cpu_load_average_(15_min) name="CPU load average (15 min)" state="0.46 load"
3:56PM DBG Sensor updated. id=distribution_version name="Distribution Version" state=
3:56PM DBG Sensor updated. id=mountpoint_home name="Mountpoint /home Usage" state="67.5 %"
3:56PM DBG Sensor updated. id=ucsi-source-psy-USBC000:001_battery_state name=" Battery State" state=unknown
3:56PM DBG Sensor updated. id=temp_nvme_sensor_1 name="Nvme Sensor 1 Temp" state="37.85 °C"
3:56PM DBG Sensor updated. id=bytes_sent_throughput name="Bytes Sent Throughput" state="<nil> B/s"
3:56PM DBG Sensor updated. id=swap_memory_total name="Swap Memory Total" state="63999832064 B"
3:56PM DBG Sensor updated. id=external_ipv4_address name="External IPv4 Address" state=1.2.3.4
3:56PM DBG Sensor updated. id=mountpoint_efi name="Mountpoint /efi Usage" state="27.1 %"
3:56PM DBG Sensor updated. id=ucsi-source-psy-USBC000:002_battery_state name=" Battery State" state=unknown
3:56PM DBG Sensor updated. id=temp_nvme_sensor_2 name="Nvme Sensor 2 Temp" state="37.85 °C"
3:56PM DBG Sensor updated. id=swap_memory_free name="Swap Memory Free" state="62820446208 B"
3:56PM DBG Sensor updated. id=mountpoint_blah name="Mountpoint /blah/" state="100 %"
3:56PM DBG Sensor updated. id=AC_battery_level name=" Battery Level" state="0 %"
3:56PM DBG Sensor updated. id=temp_thinkpad_cpu name="Thinkpad Cpu Temp" state="44 °C"
3:56PM DBG Sensor updated. id=BAT0_battery_level name="5B10W51826 Battery Level" state="98 %"
3:56PM DBG Sensor updated. id=temp_thinkpad name="Thinkpad Temp" state="34 °C"
3:56PM DBG Sensor updated. id=ucsi-source-psy-USBC000:001_battery_level name=" Battery Level" state=unknown
3:56PM DBG Sensor updated. id=temp_thinkpad_1 name="Thinkpad 1 Temp" state="0 °C"
3:56PM DBG Sensor updated. id=ucsi-source-psy-USBC000:002_battery_level name=" Battery Level" state=unknown
3:56PM DBG Sensor updated. id=temp_thinkpad_2 name="Thinkpad 2 Temp" state="35 °C"
3:56PM DBG Sensor updated. id=BAT0_battery_temperature name="5B10W51826 Battery Temperature" state="0 °C"
3:56PM DBG Location Updated.
3:56PM DBG Sensor updated. id=temp_thinkpad_3 name="Thinkpad 3 Temp" state="44 °C"
3:56PM DBG Sensor updated. id=ucsi-source-psy-USBC000:001_battery_level name=" Battery Level" state="0 %"
3:56PM DBG Sensor updated. id=temp_thinkpad_4 name="Thinkpad 4 Temp" state="44 °C"
3:56PM DBG Sensor updated. id=ucsi-source-psy-USBC000:002_battery_level name=" Battery Level" state="0 %"
3:56PM DBG Sensor updated. id=temp_coretemp_package_id_0 name="Coretemp Package Id 0 Temp" state="43 °C"
3:56PM DBG Sensor updated. id=BAT0_battery_power name="5B10W51826 Battery Power" state="0 W"
3:56PM DBG Sensor updated. id=temp_coretemp_core_0 name="Coretemp Core 0 Temp" state="43 °C"
3:56PM DBG Sensor updated. id=temp_coretemp_core_1 name="Coretemp Core 1 Temp" state="43 °C"
3:56PM DBG Sensor updated. id=temp_coretemp_core_2 name="Coretemp Core 2 Temp" state="43 °C"
3:56PM DBG Sensor updated. id=temp_coretemp_core_3 name="Coretemp Core 3 Temp" state="43 °C"
3:56PM DBG Sensor updated. id=temp_iwlwifi_1 name="Iwlwifi 1 Temp" state="50 °C"

[joshuar]

Alright, I think I can see what is going on. I'll make the D-Bus watch more general in what it triggers on and with some filtering I can get the screen lock state, without any need to know a session beforehand and without any specific desktop interface. I'll implement this in the next version, to release shortly 😄

[joshuar]

I've released v6.1.0 which I believe should fix this issue. Please try it out and let me know!

[sqshr]

Still no lock sensor present- I don't get the error string "Could not ascertain user session from D-Bus. Cannot monitor screen lock state." in the debug output, nor any mention of screen lock/unlock.

For sanity I checked if I was still getting the lock and unlock signals on the system dbus- I am! If there's any output that would help, just let me know.

[joshuar]

Hmm, I'm really unsure why this isn't working for you 😦 The code is now:

• Watching the D-Bus system bus for a message with:
  • a path namespace matching /org/freedesktop/login1/session/*
  • from the interface org.freedesktop.DBus.Properties
  • with the signal PropertiesChanged
  • containing a body which has the LockedHint property and its value.

You can monitor the messages that would trigger this on the command-line with:

dbus-monitor --system "type='signal',interface='org.freedesktop.DBus.Properties',path_namespace='/org/freedesktop/login1/session',member='PropertiesChanged'"

I get the signals with LockedHint toggling between true/false via either loginctl or with my desktop environment control.

Using the above dbus-monitor command, do you also see messages with LockedHint changing when locking/unlocking? From our previous debugging steps, I would expect that the above watch would catch the signal on your setup.

My only thought is that if you aren't seeing messages triggered on lock/unlock with the above dbus-monitor command, something isn't telling systemd-logind about the lock state. That would be weird for loginctl as it should do the right thing and follow its own spec, which it seems to do for me.

Or some restrictions on system bus access for your user are preventing the agent seeing that signal. That would hopefully be revealed with the above dbus-monitor command run as your user.

[sqshr]

So, I don't get any output from the above dbus-monitor command, which would explain why it's not working! If I run dbus-monitor --system as my user, I see:

signal time=1703234469.517539 sender=:1.3 -> destination=(null destination) serial=1334 path=/org/freedesktop/login1/session/_32; interface=org.freedesktop.login1.Session; member=Lock

on lock, and

signal time=1703234485.640237 sender=:1.3 -> destination=(null destination) serial=1338 path=/org/freedesktop/login1/session/_32; interface=org.freedesktop.login1.Session; member=Unlock

on unlock. My version into for loginctl is below.

systemd 254 (254.5-1-arch)
+PAM +AUDIT -SELINUX -APPARMOR -IMA +SMACK +SECCOMP +GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 -PWQUALITY +P11KIT -QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD +BPF_FRAMEWORK +XKBCOMMON +UTMP -SYSVINIT default-hierarchy=unified

[joshuar]

Hmm, I don't get those signals at all. Nevertheless I think I understand how it is working on your system and have made some code changes to hopefully capture those signals and set a screen lock sensor appropriately. Can you try out v6.1.1 and see if it correctly picks up your screen lock state?

[joshuar]

Hey @sqshr it sounds like this issue is now fixed? I'll close off this issue, but please try with the latest version of the agent and re-open if it is still a problem with that version.