[BUG] Screen Lock sensor not working

[azsaurr]

Go Hass Agent Version
v11.1.0

Describe the bug
Screen Lock sensor is not detecting when screen is being locked.

To Reproduce
Steps to reproduce the behaviour:

1. Lock screen.
2. screen_lock sensor in Home Assistant still shows state as Unlocked.

Expected behaviour
screen_lock sensor in Home Assistant should update to Locked.

Logs

...
... level=DEBUG msg="Preferences are valid."
... level=WARN msg="Could not init worker." linux.controller=sensor worker=abrt_problems_sensor error="unable to fetch ABRT problems from D-Bus: SystemBus: unable to get data org.freedesktop.problems.GetProblems from org.freedesktop.problems: The name is not activatable"
... level=WARN msg="Could not init worker." linux.controller=sensor worker=chrony_sensors error="chronyc is not available: exec: \"chronyc\": executable file not found in $PATH"
... level=DEBUG msg="Starting worker" worker=app_sensors
... level=DEBUG msg="Starting worker" worker=battery_sensors
... level=DEBUG msg="Starting worker" worker=network_connection_sensors
... level=DEBUG msg="Starting worker" worker=network_addresses
... level=DEBUG msg="Starting worker" worker=power_profile
... level=DEBUG msg="Starting worker" worker=oom_events_worker
... level=DEBUG msg="Starting worker" worker=user_session_event_worker
... level=DEBUG msg="Starting worker" worker=power_state_sensor
... level=DEBUG msg="Starting worker" worker=screen_lock_sensor
... level=DEBUG msg="Starting worker" worker=desktop_settings_sensors
... level=DEBUG msg="Starting worker" worker=disk_rates_sensors
... level=DEBUG msg="Starting worker" worker=disk_usage_sensors
... level=DEBUG msg="Starting worker" worker=load_averages_sensors
... level=DEBUG msg="Starting worker" worker=cpu_usage_sensors
... level=DEBUG msg="Starting worker" worker=cpu_freq_sensors
... level=DEBUG msg="Starting worker" worker=memory_usage_sensors
... level=DEBUG msg="Starting worker" worker=network_stats_worker
... level=DEBUG msg="Could not retrieve power profile." worker=power_profile error="unable to retrieve active power profile from D-Bus: SystemBus: unable to retrieve property org.freedesktop.UPower.PowerProfiles.ActiveProfile from org.freedesktop.UPower.PowerProfiles: The name is not activatable"
... level=DEBUG msg="Starting worker" worker=time
... level=DEBUG msg="Starting worker" worker=hwmon
... level=DEBUG msg="Starting worker" worker=cpu_vulnerabilities
... level=DEBUG msg="Starting worker" worker=system_info
... level=DEBUG msg="Starting worker" worker=system_info
... level=DEBUG msg="Starting worker" worker=boot_time_sensor
... level=DEBUG msg="Starting worker" worker=connection_latency
... level=DEBUG msg="Starting worker" worker=external_ip
... level=DEBUG msg="Starting worker" worker=agent_version
... level=DEBUG msg="Starting worker" worker=scripts
...
... level=DEBUG msg="Listening on websocket."
... level=DEBUG msg="Requesting authorisation for websocket."
...
... level=DEBUG msg="Sensor updated." sensor.name="Screen Lock" sensor.id=screen_lock sensor.state=true sensor.units=""
...

I've removed lines I thought might not be relevant.

Desktop (please complete the following information):

• Arch Linux
• Zen Kernel
• KDE Plasma

Additional context
I'm aware of the discussion in a previous issue #52 and can confirm that the dbus-monitor commands detect the locking/unlocking signals.

I believe the power_profile error in the logs is due to it running on a desktop and has nothing to do with screen locking, but I might be wrong.

Might be related: the session lock controls made available through MQTT on Home Assistant do not work either, but I'm able to lock and unlock through custom MQTT commands by executing loginctl lock-session and loginctl unlock-session.

[joshuar]

Hey @azsaurr that's odd! Both KDE and Arch shouldn't be issues for the screen lock sensor.

Can you run a few commands in a terminal to help debug this?

Firstly, can you get the session path with:

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

It should output something like:

method return time=1736558140.433922 sender=:1.11 -> destination=:1.832 serial=2709 reply_serial=2
   array [
      struct {
         string "3"
         uint32 1000
         string "joshua"
         string "seat0"
         object path "/org/freedesktop/login1/session/_33"
      }
...

Taking the value of the "object path", can you then run:

dbus-monitor --system "path='/org/freedesktop/login1/session/_33'"

Then lock and unlock your screen?

Hopefully, you'll see some output like:

signal time=1736558228.555507 sender=:1.11 -> destination=(null destination) serial=2730 path=/org/freedesktop/login1/session/_33; interface=org.freedesktop.DBus.Properties; member=PropertiesChanged
   string "org.freedesktop.login1.Session"
   array [
      dict entry(
         string "LockedHint"
         variant             boolean true
      )
   ]
   array [
   ]
signal time=1736558235.927527 sender=:1.11 -> destination=(null destination) serial=2736 path=/org/freedesktop/login1/session/_33; interface=org.freedesktop.DBus.Properties; member=PropertiesChanged
   string "org.freedesktop.login1.Session"
   array [
      dict entry(
         string "LockedHint"
         variant             boolean false
      )
   ]
   array [
   ]

Can you copy and paste the output in this issue?

If you aren't seeing any output, it's likely that we can't monitor the screen lock state on your system. Is your system configured with systemd and in particular, systemd-logind?

[azsaurr]

Can confirm I am able to see the output:

signal time=1736563418.116275 sender=:1.6 -> destination=(null destination) serial=2405 path=/org/freedesktop/login1/session/_33; interface=org.freedesktop.DBus.Properties; member=PropertiesChanged
   string "org.freedesktop.login1.Session"
   array [
      dict entry(
         string "LockedHint"
         variant             boolean true
      )
   ]
   array [
   ]
signal time=1736563419.424765 sender=:1.6 -> destination=(null destination) serial=2407 path=/org/freedesktop/login1/session/_33; interface=org.freedesktop.DBus.Properties; member=PropertiesChanged
   string "org.freedesktop.login1.Session"
   array [
      dict entry(
         string "LockedHint"
         variant             boolean false
      )
   ]
   array [
   ]

However,

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

yields 2 results:

method return time=1736563498.730749 sender=:1.6 -> destination=:1.958 serial=2413 reply_serial=2
   array [
      struct {
         string "1"
         uint32 1000
         string "user"
         string ""
         object path "/org/freedesktop/login1/session/_31"
      }
      struct {
         string "3"
         uint32 1000
         string "user"
         string "seat0"
         object path "/org/freedesktop/login1/session/_33"
      }
   ]

and

> logintctl list-sessions
SESSION  UID USER SEAT  LEADER CLASS   TTY  IDLE SINCE
      1 1000 user   -     896    manager -    no   -    
      3 1000 user   seat0 1438   user    tty1 no   -    

2 sessions listed.

Maybe the screen_lock sensor is listening to the first session?

I'm not sure why the first session is there though, and I can't seem to terminate it either:

> loginctl terminate-session 1
> loginctl list-sessions
SESSION  UID USER SEAT  LEADER CLASS   TTY  IDLE SINCE
      1 1000 user   -     896    manager -    no   -    
      3 1000 user   seat0 1438   user    tty1 no   -    

2 sessions listed.

[azsaurr]

After dozens of reboots, I find that the screen_lock sensor does work sometimes, and it is only when the seat0 session is the first element in the array:

> dbus-send --system --print-reply --dest=org.freedesktop.login1 /org/freedesktop/login1 org.freedesktop.login1.Manager.ListSessions
method return time=1736596306.474213 sender=:1.6 -> destination=:1.92 serial=359 reply_serial=2
   array [
      struct {
         string "3"
         uint32 1000
         string "user"
         string "seat0"
         object path "/org/freedesktop/login1/session/_32"
      }
      struct {
         string "2"
         uint32 1000
         string "user"
         string ""
         object path "/org/freedesktop/login1/session/_33"
      }
   ]

> loginctl list-sessions
SESSION  UID USER SEAT  LEADER CLASS   TTY  IDLE SINCE
      2 1000 user   -     1338   manager -    no   -    
      3 1000 user   seat0 1318   user    tty1 no   -    

2 sessions listed.

I did some reading and apparently the manager session is normal and is supposed to be spawned for every user. I'm not sure whether the inconsistent ordering is normal too or just a problem on my machine. Either way, I tried following the code, maybe checking for "seat0" in GetSessionPath() here could help?

[joshuar]

Hey nice D-Bus spelunking @azsaurr! I think checking whether the session is a "seat" or not is the right thing to do as you've suggested. Let me wrangle some code to do that. I'll make sure that this change will end up in the next release. Stay tuned and thanks for the debugging help!

[azsaurr]

Thanks, I'd do it myself but I wasn't sure if that was the right way to go about it, and I'm not familiar at all with Go syntax.

[metalmatze]

I'm running Hyprland with swaylock for locking my screen.
Seems like the sensor isn't updated either. I'm happy to investigate with my environment some more.

[azsaurr]

@metalmatze are you able to see the screen_lock sensor being updated in the debug logs? Hyprland seems to use the same D-Bus destination and path, so maybe you can try running the commands above and share the outputs?