14

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
  2. Wait for the computer to hibernate
  3. Open the lid
  4. Press the power button
  5. Provide the login password followed by Enter

and

  1. Lock the desktop
  2. Same steps as above

Tracing the code:

  1. The line which prints the error message: error1 ("Could not locate a running %s.\n", progName);
  2. That happens if messageToSend is truthy and type != XA_INTEGER
  3. 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:

  1. 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:

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.

  • Which unix are you using? – kasperd Nov 6 '15 at 9:27
  • I am running into this same issue. I haven't looked too deeply into it, but I would love to know an answer as well. – HalosGhost Nov 8 '15 at 1:20
  • How are you starting it? I found the same thing recently when starting it from .xinitrc: I switched to a --user service file and it is no longer an issue... – jasonwryan Nov 15 '15 at 0:50
  • 1
    Playing a video with mpv (but not mplayer) triggers the issue for me. Both players have empty configurations. – jrm Mar 27 '16 at 13:51
  • 1
    A less-than-optimal workaround for this trigger is to add stop-screensaver=no to ~/.mpv/config. Of course, this means you have to manually disable locking when playing videos with mpv. – jrm Mar 27 '16 at 14:08
5

For me, the xautolock process was still running in the background, but it wasn't listening to any xautolock -locknow commands. As mentioned by @jrm, an application must be suppressing the "screensaver". For both of us, this was due to mpv (video player) disabling the screensaver.

For mpv, the fix is to add the following to ~/.config/mpv/config or ~/.mpv/config:

stop-screensaver=no

If you do not use mpv, it might be another application disabling the screensaver. Try some commonly used ones out to see which one it is.


If you want to prevent automatic screen locking during video playback, one common way is to use xautolock's "corners" feature:

xautolock -corners 000- -cornersize 30

With the above command, if you put your mouse cursor in the bottom right corner of the screen (within a 30px radius), auto-locking will be temporarily disabled.


One more thing to try is the -resetsaver option:

xautolock -resetsaver

Or the -detectsleep option:

xautolock -detectsleep
  • Good tips, thanks! I've been aware of my video player (VLC) disabling screen locking for many years, but honestly this issue is now so far back that I can't recall if my mind had simply blanked over this fact. Anyway I've stopped using xautolock, so the question is a bit moot now. Marking as accepted as the most useful answer so far. If anyone has the exact same issue I can delete this question to avoid a duplicate. – l0b0 Jun 29 '17 at 10:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.