Comportamento diferente de systemctl suspender quando executado via ligação de chave i3 wm

Question

Estou usando o gerenciador de janelas do i3 para azulejos em combinação com o light-locker para bloquear a tela.

O Light-locker exibe uma mensagem de bloqueio no TTY bloqueado e mostra a tela de senha em um segundo TTY.

Ao fechar a tampa do notebook ou executar systemctl suspend de um emulador de terminal, as mensagens de bloqueio aparecem por um curto período e, em seguida, o sistema entra no estado S3. No reinício, a mensagem de bloqueio fica visível por um curto período de tempo novamente, então o light-locker muda para a entrada de senha-TTY, que é o comportamento desejado.

O problema ocorre quando eu vinculo o comando systemctl a uma chave específica através do arquivo de configuração do i3 assim:

bindsym s exec --no-startup-id systemctl suspend, mode "default"

Ao pressionar $ mod + s, a tela fica preta imediatamente, sem mostrar a mensagem de bloqueio.

Ao reiniciar, a tela é ligada, exibindo a área de trabalho desbloqueada por meio segundo, depois as mensagens de bloqueio piscam por uma fração de segundo e, em seguida, a entrada de senha-TTY é mostrada.

Esse comportamento não é aceitável, pois expõe a área de trabalho após a suspensão do computador, até mesmo a área de trabalho fica visível por um curto período de tempo.

Meu palpite é que, ao usar o bash para executar systemctl suspend , o comando leva mais tempo ou sth. assim, possibilitando que o light-locker mude para a mensagem de bloqueio antes que o sistema seja suspenso.

Como posso evitar ou contornar o comportamento diferente da associação de chaves?

    

Answer 1

Consegui resolver o problema usando os seguintes comandos:

(sleep 0.5 && systemctl suspend) &

Seria interessante saber por que exatamente o comando sleep é necessário para obter o comportamento desejado.