I am using DWM on Debian 12, and I have configured xautolock to automatically lock my screen using slock after a period of inactivity. Here is the command I am using: xautolock -time 9 -locker slock -notify 60 -notifier "notify-send 'Locking in 1 minute' 'The system will be locked in one minute!'" My question is: **If xautolock triggers slock, and then while slock is active there is no activity, will xautolock attempt to start another instance of slock, effectively locking the screen twice?** I want to ensure that only a single instance of slock runs at any given time. If xautolock keeps **re-triggering** slock even when the screen is already locked, it could cause issues. ## What I have tried: ## 1. Checking man xautolock, but I didn't find explicit documentation on how it handles already active lockers. 2. Running ps aux | grep slock while slock is active, but I haven't tested whether a second instance could be started. 3. Considering using pgrep or pidof in the -locker command to prevent multiple instances, but I want to understand how xautolock behaves by default before implementing a workaround. Would xautolock attempt to lock the screen again while slock is already running, and if so, what would be the best way to prevent multiple instances? *Any insights or suggestions would be greatly appreciated!*

I'm using manjaro (5.8.18-1-MANJARO) and the i3 window manager. I'm trying to lock the screen then suspend activity after given amounts of idle time. I've found that xautolock should suit my needs using both the -locker and -killer flags. My i3 config contains the following :

--no-startup-id xautolock -time 5 -locker blurlock -notify 15 -notifier "notify-send 'Screen will lock in 15 s'" -detectsleep -killtime 60 -killer "systemctl suspend"

However, this doesn't seem to work: 1) The locker part works fine, but system doesn't suspend after 60 minutes. 2) If I suspend the system manually (I'm using a modified version of the i3exit script, the executed command is xautolock -locknow && systemctl suspend), then the system suspends *again* shortly after i resumed it. This behavior started very recently, I think after a system update, and I don't think I've changed anything else than the i3exit myself in system settings / config. I don't know what could be putting the system to sleep again since I don't have any power-manager activated to my knowledge. Thanks for your help !

xautolock is clearly running : $ ps wafux | grep [x]autolock user 21410 0.0 0.0 20124 2628 ? S Nov05 0:04 xautolock -time 10 -notify 30 -notifier notify-send --urgency low --expire-time=10000 -- 'Locking screen in 30 seconds' -locker slock However, when I try to lock it : $ xautolock -locknow Could not locate a running xautolock. If I spin up another xautolock it works: $ xautolock -time 10 -notify 30 -notifier "notify-send --urgency low --expire-time=10000 -- 'Locking screen in 30 seconds'" -locker slock& [2] 18828 $ ps wafux | grep [x]autolock user 21410 0.0 0.0 20124 2628 ? S Nov05 0:04 xautolock -time 10 -notify 30 -notifier notify-send --urgency low --expire-time=10000 -- 'Locking screen in 30 seconds' -locker slock user 18828 0.0 0.0 20124 2708 pts/1 S 08:30 0:00 \_ xautolock -time 10 -notify 30 -notifier notify-send --urgency low --expire-time=10000 -- 'Locking screen in 30 seconds' -locker slock $ xautolock -locknow # Runs fine and locks the desktop What gives? By now I've seen this on both my desktop and laptop. Please note that at least the first time after boot locking works fine. It's only after some unknown time or event that it starts failing. --- I have *not* been able to reproduce this reliably. That is, I've tried the following approaches on my laptop and in both cases the screensaver shortcut/command actually locks the desktop afterwards: 1. Close the lid 1. Wait for the computer to hibernate 1. Open the lid 1. Press the power button 1. Provide the login password followed by Enter and 1. Lock the desktop 1. Same steps as above --- Tracing the code: 1. The line which prints the error message : error1 ("Could not locate a running %s.\n", progName); 1. That happens if messageToSend is truthy and type != XA_INTEGER 1. It looks like type is set in the following statement: (void) XGetWindowProperty (d, root, semaphore, 0L, 2L, False, AnyPropertyType, &type, &format, &nofItems, &after, (unsigned char**) &contents); Does this mean that whether the running xautolock is detected can depend on the *window* that is focused? I'm also wondering if this call could be related to this known bug : > 4. The -disable, -enable, -toggle, -exit, -locknow, -unlocknow, and -restart options depend on access to the X server to do their work. This implies that they will be suspended in case some other application has grabbed the server all for itself. --- Is it possible that xautolock conflicts with xss-lock, both of which are using slock? In addition to the xautolock line above I also have this line in .xprofile : xss-lock slock & --- Since both xautolock and xss-lock can call slock, I'm suspecting that the problem goes something like this: - xautolock runs slock after 10 minutes of inactivity. - xss-lock *also* tries to run slock after 10 minutes : $ xset q | grep --after-context=2 --line-regexp --fixed-strings 'Screen Saver:' Screen Saver: prefer blanking: yes allow exposures: yes timeout: 600 cycle: 600 - Only one slock client is actually spawned. - xss-lock kills the wrong slock, which causes xautolock to crash or give up. Since xss-lock can detect laptop sleep I'd like to use it instead of xautolock, but I can't seem to make xss-lock work with notify-send.

I have a slightly different way of using xautolock: After I lock the screen (using i3lock in my case), I want the display to turn off after some period of time of inactivity. AND I want it to re-turn off if it detects activity, turns on the screen, but the computer isn't unlocked. Here is the script I have:

/bin/bash

function lockfunc {
    if [[ "$1" = -sleep ]]; then
        i3lock -t -i $backgroundimg &&  xautolock -time 1 -locker 'xset s activate' &
        while [[ $(pgrep -x i3lock) ]]; do # loop while computer is locked
            echo $(date) '| i3lock running'
            if [[ $(pgrep -x xautolock) ]]; then echo $(date) '| xautolock running'; fi
            # if $(pgrep -x xautolock); then echo $(date) '| i3lock running'; fi
            sleep 5
        done
        echo $(date) '| exit i3lock while loop'
        xautolock -exit # stop xautolock when unlocked
    else
        i3lock -t -i $backgroundimg
    fi
    return 0}

lockfunc -sleep

While the behavior mostly works, the huge issue right now is that **after (exactly) one minute of the screen being off, it turns back on without any interaction.** Behavior timeline:

00:00 -> start the lockfunc
01:00 -> screen turns off
02:00 -> screen turns on
07:00 -> screen doesn't turn back off, stop test

The debug echo statements in the script above didn't really show anything changing during that time: both i3lock and xautolock were still running the whole time. Any ideas why this is happening?

Would like to disconnect an nic after a minute of user inactivity, where inactivity is defined as no mouse clicks or wheel scrolls. Mouse movement is to be ignored so xscreensaver is not suitable and neither is xautolock. How can mouse events be detected from the command line and differentiated?

I use xautolock to lock the screen and suspend my laptop after a given amount of time of inactivity. This works fine. This is how xautolock is started from .xsessionrc: xautolock -time 60 -detectsleep -locker '~/bin/lockscreen --suspend' & The ~/bin/lockscreen script does, among other things, ssh-add -D to remove all SSH keys from the running SSH agent. This, however does not work when xautolock is spawned from .xsessionrc - the ssh-add -D command complains that it cannot talk to the authentication agent. However, I can ssh-add -D from my terminal just fine, and if I pkill xautolock and then run the xautolock command from my .xsessionrc in a terminal, everything works as expected. Why can't the ssh-add -D process spawned from xautolock spawned from .xsessionrc talk to the SSH agent, but ssh-add -D spawned from xautolock spawned from a regular terminal can? ps auf shows this tree: root 24126 0.0 0.1 105812 5032 tty1 Ss 18:34 0:00 /bin/login -- andreas 24132 0.0 0.1 40232 4956 tty1 S 18:34 0:00 \_ -zsh andreas 24140 0.0 0.0 4328 1576 tty1 S+ 18:34 0:00 \_ /bin/sh /usr/bin/startx andreas 24162 0.0 0.0 15944 1952 tty1 S+ 18:34 0:00 \_ xinit /etc/X11/xinit/xinitrc -- /etc/X11/xinit/xserverrc :0 vt1 -auth /tmp/serverauth.afXu0ohTRz root 24163 1.4 0.5 165868 20048 tty1 S 18:34 0:02 \_ /usr/bin/X -nolisten tcp :0 vt1 -auth /tmp/serverauth.afXu0ohTRz andreas 24169 0.0 0.2 113572 10600 tty1 S 18:34 0:00 \_ x-window-manager andreas 24203 0.0 0.7 489436 26380 tty1 Sl 18:34 0:00 \_ nm-applet andreas 24204 0.0 0.0 20140 2700 tty1 S 18:34 0:00 \_ xautolock -time 60 -detectsleep -locker ~/bin/lockscreen --suspend andreas 24209 0.0 0.0 22196 2680 tty1 S 18:34 0:00 \_ /usr/bin/unclutter -idle 1 -root andreas 24212 0.0 0.0 10688 340 ? Ss 18:34 0:00 \_ /usr/bin/ssh-agent /usr/bin/dbus-launch --exit-with-session x-window-manager My only working theory is that because xautolock is started before the SSH agent, the forked ssh-add command doesn't know about the agent's existence, but that seems very odd to me.

I'm trying to make a simple script to put my computer to sleep if it runs on battery unattended. I have this simple script: #!/bin/sh if [ cat /sys/class/power_supply/ADP1/online -eq 0 ]; then cat /sys/class/power_supply/ADP1/online; # actual sleep command goes here fi When I run it with xautolock -time 1 -noclose -locker /path/to/script.sh, it works as expected, printing zeroes every minute when the AC is disconnected, and sitting still if I move the mouse or connect the power adapter. So far so good. However, for an unknown reason I fail to get this working as an one-liner: xautolock -time 1 -noclose -locker "if [ cat /sys/class/power_supply/ADP1/online -eq 0 ]; then cat /sys/class/power_supply/ADP1/online; fi" Here's a sample output: 0 # I start with the charger disconnected 0 0 # Here I connect the charger 1 1 ^C As you can see, the value in /sys/class/power_supply/ADP1/online changes as expected, yet the condition seems to keep the initial value. Similarly, if I start the script with the AC power connected, nothing is ever printed in the terminal afterwards. It looks like the command substitution is only evaluated the first time, and the output is reused afterwards. Is there a reasonable explanation as to why this is happening? PS. I have tried the alternative substitution syntax $(), with the same results.

I want to have my screen lock and backlight fade out after some delay, and then I want to have the backlight fade back in when I move the cursor or press a button. Having the screen fade out is easy enough with xautolock, but I can't figure out a way to have to fade back in when I do a keyboard or mouse action. Is it possible to achieve this with xautolock, or perhaps another tool?

I've defined the following service to start a screen locker before suspending : $ cat /etc/systemd/system/screenlock.service [Unit] Description=Lock X session using slock Before=sleep.target [Service] User=my_user Environment=DISPLAY=:0 ExecStart=/usr/bin/xautolock -locknow [Install] WantedBy=sleep.target It is loaded when booting: $ systemctl status screenlock.service ● screenlock.service - Lock X session using slock Loaded: loaded (/etc/systemd/system/screenlock.service; enabled) Active: inactive (dead) and it is run at some point between triggering suspend to RAM and resuming work: $ systemctl status screenlock.service ● screenlock.service - Lock X session using slock Loaded: loaded (/etc/systemd/system/screenlock.service; enabled) Active: inactive (dead) Sep 17 08:22:22 machine systemd[1] : Starting Lock X session using slock... Sep 17 08:22:22 machine systemd[1] : Started Lock X session using slock. But **if it's run *before* suspending, why do I see a flicker of the desktop before the screen locker turns on when resuming?** Is Before or sleep.target not defined as one would expect? Is xautolock or slock faulty? (I've verified that there's no other service interfering by disabling this one, suspending, resuming, and getting no screen locker.)