Linux – Why does desktop locking stop working after some time

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:

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.