xautolock
è chiaramente in esecuzione :
$ 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
Tuttavia, quando provo a bloccarlo :
$ xautolock -locknow
Could not locate a running xautolock.
Se ne giro un altro xautolock
funziona:
$ 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
Cosa dà?
Ormai l'ho visto su desktop e laptop. Si noti che almeno la prima volta dopo il blocco dell'avvio funziona correttamente. È solo dopo un periodo sconosciuto o un evento che inizia a fallire.
Sono non stato in grado di riprodurre questo modo affidabile. Cioè, ho provato i seguenti approcci sul mio laptop e in entrambi i casi il collegamento / comando screensaver in realtà blocca il desktop in seguito:
- Chiudi il coperchio
- Attendere il letargo del computer
- Apri il coperchio
- Premi il pulsante di accensione
- Fornire la password di accesso seguita da Enter
e
- Blocca il desktop
- Stessi passi come sopra
Tracciare il codice:
- La riga che stampa il messaggio di errore :
error1 ("Could not locate a running %s.\n", progName);
- Succede se
messageToSend
è vero etype != XA_INTEGER
Sembra che
type
sia impostato nella seguente dichiarazione:(void) XGetWindowProperty (d, root, semaphore, 0L, 2L, False, AnyPropertyType, &type, &format, &nofItems, &after, (unsigned char**) &contents);
Questo significa che il xautolock
rilevamento della corsa può dipendere dalla finestra focalizzata? Mi chiedo anche se questa chiamata potrebbe essere correlata a questo bug noto :
- Le opzioni -disable, -enable, -toggle, -exit, -locknow, -unlocknow e -restart dipendono dall'accesso al server X per fare il loro lavoro. Ciò implica che saranno sospesi nel caso in cui un'altra applicazione abbia afferrato il server da solo.
È possibile che sia in xautolock
conflitto con xss-lock
entrambi i quali stanno usando slock
? Oltre alla xautolock
riga sopra ho anche questa riga in .xprofile :
xss-lock slock &
Dal momento che entrambi xautolock
e xss-lock
posso chiamare slock
, sospetto che il problema vada in questo modo:
xautolock
funzionaslock
dopo 10 minuti di inattività.xss-lock
prova anche a correreslock
dopo 10 minuti :$ xset q | grep --after-context=2 --line-regexp --fixed-strings 'Screen Saver:' Screen Saver: prefer blanking: yes allow exposures: yes timeout: 600 cycle: 600
slock
Viene effettivamente generato un solo client.xss-lock
uccide ciò che è sbagliatoslock
, causando ilxautolock
crash o la rinuncia.
Dal momento che è in xss-lock
grado di rilevare la sospensione del laptop, mi piacerebbe usarlo invece di xautolock
, ma non riesco a farlo xss-lock
funzionare notify-send
.
.xinitrc
ho avviato : sono passato a un --user
file di servizio e non è più un problema ...
stop-screensaver=no
a ~/.mpv/config
. Naturalmente, questo significa che devi disabilitare manualmente il blocco durante la riproduzione di video con mpv.