I’m setting up a nixos box. I’m trying to keep everything minimum, I use i3 as WM without a DE. Currently I’m trying to figure out how to configure nixos to:
Sleep (hybrid-sleep preferably) after idle for certain time.
Lock the screen before sleep, so password is required after wake up.
❦ 24 août 2020 05:40 +00, Leira Hua via NixOS Discourse:
Sleep (hybrid-sleep preferably) after idle for certain time.
Lock the screen before sleep, so password is required after wake up.
What is the preferred nixos/i3 way to do it?
I don’t think there is anything specific to NixOS. For the first point,
this is the job of systemd-logind. In services.logind.extraConfig, you
can add:
IdleAction=hybrid-sleep
IdleActionSec=30min
To lock screen before sleep, you can use xss-lock.
# hybrid sleep when press power button
services.logind.extraConfig = ''
HandlePowerKey=suspend
IdleAction=suspend
IdleActionSec=1m
'';
# screen locker
programs.xss-lock.enable = true;
And I have this line in in my i3 config:
exec --no-start-id xset s 180 10
I’ve verified:
xset s activate works, screen locked.
wait for 3 minutes, screen locked.
systemctl suspend works, screen locked when wake up.
Power button worked, system suspended when I press power button.
No matter how long I wait, the machine didn’t suspend itself.
It seems to me logind didn’t get the idle hint, for some reason, despite xss-lock did lock screen after idle for 3 minutes. For some reason xss-lock got the idle hint, but logind didn’t. My questions are:
How idle is detected?
Do xss-lock and logind share the same source of idle hint, or not?
How does logind detects/notified idle?
How do I further debug this issue?
BTW, I just use a vanilla i3wm with no DE. If DE is the component providing idle detection, then what should I use for idle detection purpose with i3?
PS, I didn’t use hybrid-sleep in the config. hybrid-sleep didn’t work for me, it woke up with a black screen. Seems to be nvidia GPU related issue, but that’s an irrelevant story to the topic.
❦ 6 septembre 2020 20:20 GMT, Leira Hua via NixOS Discourse:
Do xss-lock and logind share the same source of idle hint, or not?
xss-lock monitors the X session for idleness and manages the hint for
logind. You can check IdleHint with loginctl show-session 1 (get the
session number with loginctl). Check through SSH once the lock screen
has kicked in.
Thank you very much, @bernat! I was always confused of the whole process. Let me check if I understand it correctly now:
X monitors user’s activity. If the user of X become inactive for a period of screensavor_time_out, X triggers a start_screensaver event.
xset s sets screensavor_time_out.
xss-lock is a start_screensaver event handler. It does 2 things when received an event:
a. Start a notifier command, typically a locker app, default to i3lock.
b. Send an idle_hint to the login manager.
logind is the login manager of systemd, it listens to idle_hints from all the sessions. When all sessions are idle, after IdleActionSec period, it takes the IdleAction.
So xss-lock listens to start_screensaver event, and sets the idle_hint which logind listens to. Then the problem here can be:
xss-lock didn’t set the idle_hint correctly.
logind didn’t get the idle_hint correctly.
Some sessions other than the idled X session was still active.
logind didn’t take the IdleAction after IdleActionSec.
Then:
How to confirm 1.? Where is the log for X (new to systemd)? Does xss-lock have entries in X logs?
Below is My loginctl show-session output. But I wonder, when can I see IdleHint=yes? After xss-lock sets the idle_hint, but before IdleActionSec passes, and exactly within this window?
❦ 6 septembre 2020 22:26 GMT, Leira Hua via NixOS Discourse:
How to confirm 1.? Where is the log for X (new to systemd)? Does xss-lock have entries in X logs?
Below is My loginctl show-session output. But I wonder, when can
I see IdleHint=yes? After xss-lock sets the idle_hint, but
before IdleActionSec passes, and exactly within this window?
Yes. If you can’t use SSH to check that, use something like sleep 120; loginctl show-session 1.
I set the screensavor_time_out to 30s with xset s 30. Then I ran sleep 60; loginctl show-session 1. It did lock after 30s, but after another 70s or so, I unlocked it. loginctl printed:
I stopped the xss-lock service by systemctl --user stop xss-lock, and run xss-lock -- i3lock -n in command line. This time, it did lock after 30s, and it even suspended after another 60s, as IdleActionSec=1m. And when I woke it up and unlock, I saw loginctl printed IdleHint=yes.
So it worked when starting xss-lock in command line directly. But it didn’t work as a systemd user service.
systemctl --user show xss-lock shows FragmentPath=/nix/store/r8cx06ach9vqjvk7fp32fxbqqz30pkwb-unit-xss-lock.service/xss-lock.service. I went to that file, and attempted to recreated the exact command line used with this user service:
❦ 8 septembre 2020 05:07 GMT, Leira Hua via NixOS Discourse:
What might be the reason that xss-lock.service couldn’t report idle
hint?
Maybe you didn’t import the current X environment into systemd? This
would prevent access to DBUS user-session. Check with systemctl --user show-environment | grep DBUS.
Maybe you hit nixos/displayManager: add XDG_SESSION_ID to systemd user environment by evenbrenden · Pull Request #93764 · NixOS/nixpkgs · GitHub. Currently, calling loginctl lock-session will not trigger xss-lock when run as a user service because it doesn’t know what session to use. Could be the case for idle hints as well. You could try passing --session [session ID] to programs.xss-lock.extraOptions using your current session ID just to check if this is it. Make sure you run systemctl --user restart xss-lock.service after rebuilding.