I’ve had issues with elogind for quite some time now. I finally had gotten it resolved when I switched to Artix - everything seemed to be working fine. Then Artix decided to drop support for Xlibre and move back to Xorg - as soon as I updated, my laptop kept going to sleep after 30 minutes even when I was active with the mouse and the keyboard. Not sure if the Xlibre support being dropped was the culprit, but it seems like it.
Part of my reason for sticking with a distribution like Artix is to steer away from the monolith that is systemd, but I’m slowly becoming more systemd-pilled the more dumb issues like this I have. Except on the other hand, elogind is a part of systemd, so I’m not sure if this should be a point for or against systemd. In particular though, I miss the systemd logging and journalctl. In my experience with OpenRC and Runit, logging sucks - or I’m not doing something right. I’m not sure which.
So here was the issue and how I ultimately fixed it. For context, my stack looks like this:
- Artix Linux with OpenRC init system
- elogind and dbus (as installed by default on Artix)
- Xorg with bspwm as the window manager, startup scripts handled through startx that runs .xinitrc which then runs .xprofile
- xss-lock as the automatic locker using slock as the screen lock, along with xset to handle screensaver
Figuring out the precise issue took some digging. I figured that I might be not launching the window manager correctly with dbus, or xss-lock may not be properly setting IdleHint for elogind (in any event, whatever was supposed to be updating IdleHint was not). My testing ultimately led to me understanding that elogind was the culprit, and IdleHint was not getting updated because my SessionType was tty and not x11. Setting the XDG_SESSION_TYPE environment variable manually or in my zshrc did nothing, as apparently that is set upon login and doesn’t affect anything after that. The whole stack is impossible to wrap my head around. I tried a bunch of different things, including installing session managers (sddm and lightdm) - those DID fix the IdleHint issue, but they weren’t starting random programs. Not just startup scripts, either - program binaries like my blue light filter redshift were not launching, and my hotkey daemon sxhkd was working but random keybinds were not. (Now that I think about it more, that may have had something to do with the PATH variable not being set correctly - instead of me the user launching via startx with my zsh environment, the sddm binary was launching the window manager and all associated startup scripts. I can’t recall if redshift was a program with a custom path, but the keybinds that weren’t working were for a dmenu script in my ~/.local/bin directory, and two scripts I use for remaps and setting the background were also not working. But I digress.)
Once I figured out the issue, figuring out a solution was even harder. The only related question I could find used the PAM systemd module to set the XDG_SESSION_TYPE (and of course I don’t have systemd), and the only other answer to that question was someone giving up and using sddm.
I caved and asked AI. I have a Copilot premium for work, I was using my work laptop because my Artix system was in shambles from my testing, and my traditional searching was going nowhere. I find it deeply uninteresting to read AI output, so instead here is my prompt:
I am on an Artix Linux system using OpenRC as the init system (no
systemd). I am using standaloneelogindfor user login and seat management,xss-lockfor automatic locking along withxsetand dpms withslockas the screen lock utility. I do not have a session manager, such assddmorlightdmset up - I log into the system and usestartxto start the Xorg session.I am running into the following issue: elogind puts the system to sleep automatically after the configured
IdleActionSecvalue in/etc/elogind/logind.conf, regardless of user activity. Investigating theIdleHintvalue in a session, it always returnsIdleHint=yesafter a certain amount of time, and this is never updated.Trying to set
IdleHintwithdbusgives me an error that this is not supported on non-graphical or non-user sessions. Indeed, when I return theSessionTypevalue, I getttyinstead ofx11.
- I have ruled out
xsetand the autolock utility (xss-lock- the same occurs withxautolock).- I thought maybe it was a
dbusissue. I tried launching my window manager in~/.xinitrcwithexec /bin/bspwm,exec dbus-launch --exit-with-session /bin/bspwm,exec dbus-run-session /bin/bspwm- all of these give the same behavior.- I tried setting the
$XDG_SESSION_TYPEenvironment variable tox11by exporting that value in my~/.zshrcor~/.bashrc- the variable updated, but it had no effect onelogind’s behavior.The only successful attempt at changing this behavior I have had leads to other issues - I installed
sddmand added it to the boot runlevel in OpenRC. It works - I log in, it starts my window manager as configured in.xinitrc. As mentioned, though, I have other issues - some programs in my.xprofiledo not start correctly. It’s not an obvious pattern, either. Some of the programs are user scripts that don’t run. Others are actual binaries that simply do not get executed. My hotkey daemon (sxhkd) starts and runs fine, but random hotkeys do not work unless it is killed and restarted. Running any program or script manually that has failed after the window manager has started works fine - the problem is getting it to start automatically with the window manager. I also tried moving the program / script startup to the window manager configuration file to see if the processing order was affecting things. This made absolutely no difference.My priority is to keep my system free of a session manager and solve this through starting my window manager correctly through
dbusand setting theSessionTypevariable correctly so that theIdleHintvalue gets updated correctly. However, I am open to the alternative of configuringsddmso that my startup scripts and programs start if that is the easier route.
It gave me a few options - edit PAM to set the session type, use a script to update IdleHint, or fix the SDDM issues by setting the PATH variable elsewhere. The best suggestion it gave, though, was screw using elogind’s timer - just use xautolock instead.
Thus, it was simply a matter of removing the idle timers from elogind, then changing the xss-lock line in my ~/.xprofile to be something like the below:
xautolock -time 10 -locker slock -killtime 20 -killer "loginctl suspend-then-hibernate"
EOF