xautolock
está claramente em execução :
$ 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
No entanto, quando tento bloqueá-lo :
$ xautolock -locknow
Could not locate a running xautolock.
Se eu girar outro xautolock
, funciona:
$ 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
O que da?
Até agora eu já vi isso no meu desktop e laptop. Observe que pelo menos a primeira vez após o bloqueio de inicialização funciona bem. Somente após algum tempo ou evento desconhecido é que começa a falhar.
Eu não fui capaz de reproduzir isso de forma confiável. Ou seja, tentei as seguintes abordagens no meu laptop e, em ambos os casos, o atalho / comando do protetor de tela realmente bloqueia a área de trabalho depois:
- Feche a tampa
- Aguarde o computador hibernar
- Abra a tampa
- Pressione o botão liga / desliga
- Forneça a senha de login seguida por Enter
e
- Bloquear a área de trabalho
- Os mesmos passos acima
Rastreando o código:
- A linha que imprime a mensagem de erro :
error1 ("Could not locate a running %s.\n", progName);
- Isso acontece se
messageToSend
for verdade etype != XA_INTEGER
Parece que
type
está definido na seguinte declaração:(void) XGetWindowProperty (d, root, semaphore, 0L, 2L, False, AnyPropertyType, &type, &format, &nofItems, &after, (unsigned char**) &contents);
Isso significa que se a execução xautolock
é detectada pode depender da janela que está focada? Também estou querendo saber se esta chamada pode estar relacionada a este bug conhecido :
- As opções -disable, -enable, -toggle, -itit, -locknow, -unlocknow e -restart dependem do acesso ao servidor X para fazer seu trabalho. Isso implica que eles serão suspensos caso algum outro aplicativo pegue o servidor por si só.
É possível que xautolock
conflitos com xss-lock
ambos estejam sendo usados slock
? Além da xautolock
linha acima, também tenho esta linha em .xprofile :
xss-lock slock &
Uma vez que tanto xautolock
e xss-lock
pode chamar slock
, eu estou suspeitar que o problema é algo como isto:
xautolock
é executadoslock
após 10 minutos de inatividade.xss-lock
também tenta executarslock
após 10 minutos :$ xset q | grep --after-context=2 --line-regexp --fixed-strings 'Screen Saver:' Screen Saver: prefer blanking: yes allow exposures: yes timeout: 600 cycle: 600
- Somente um
slock
cliente é realmente gerado. xss-lock
mata o erradoslock
, o que fazxautolock
com que caia ou desista.
Desde que xss-lock
pode detectar o sono do laptop, eu gostaria de usá-lo em vez de xautolock
, mas não consigo xss-lock
trabalhar notify-send
.
.xinitrc
: eu mudei para um --user
arquivo de serviço e já não é um problema ...
stop-screensaver=no
a ~/.mpv/config
. Obviamente, isso significa que você deve desativar manualmente o bloqueio ao reproduzir vídeos com mpv.