Eu gostaria de suspender meu laptop usando at
:
echo "systemctl suspend" | at now + 5 minutes
A suspensão não acontece, em vez disso, encontro um e-mail at
de /var/spool/mail/me
:
Failed to set wall message, ignoring: Interactive authentication required.
Failed to suspend system via logind: Interactive authentication required.
Failed to start suspend.target: Interactive authentication required.
See system logs and 'systemctl status suspend.target' for details.
Tudo bem, logind
requer autenticação quando at
executa systemctl suspend
. Isso é interessante, pois quando executo systemctl suspend
diretamente, sem at
, não é necessária autenticação e a máquina entra em suspensão.
Certifiquei-me de que os comandos executados com at
sejam executados pelo mesmo usuário não root que os comandos executados diretamente usando echo "echo $(who) > who.txt" | at now
.
Suspeitando que a autenticação é necessária at
porque executa os comandos via /bin/sh
(que é um alias para bash), executei systemctl suspend
após iniciar /bin/sh
: Suspending acontece imediatamente sem autenticação, indicando que o shell aninhado não é o motivo pelo qual a suspensão falha quando feita com at
.
Recebo o mesmo comportamento e e-mails muito semelhantes ao fazer echo "reboot" | at now
e echo "shutdown now" | at now
.
Minha pergunta é: Como logind
descobrir que é at
que tenta suspender, reinicializar ou desligar a máquina e como posso dizer logind
que ela deve permitir at
a execução desses comandos sem autenticação?
Estou no Arch Linux 4.18.1 com a at
versão 3.1.19.
Presumivelmente, os comandos executados por
at
estão em um ambiente diferente, sem acesso ao seu dispositivo tty e às configurações do dbus e assim por diante.Systemd tem sua própria versão do
at
comando. Você pode usá-lo para executar seu comando em um ambiente que parece estar ok para outros comandos do systemd. Então use o comando equivalente:Para uma precisão perfeita no tempo de espera de 5 minutos, você precisa adicionar a opção
--timer-property=AccuracySec=1
.