Respostas:
at 18:00 shutdown now
cria um trabalho "at", que é executado no horário especificado pelo at
daemon ou talvez pelo cron
daemon, dependendo do seu sistema.
shutdown 18:00
inicia um processo no seu shell que aguarda até o tempo especificado e, em seguida, executa o desligamento. Este comando pode ser encerrado se, por exemplo, sua sessão do shell for encerrada.
O resultado líquido na maioria dos casos será o mesmo: o sistema é encerrado às 18:00.
Uma diferença é que, se você usar at
, o trabalho será armazenado e se o sistema for desligado por outros meios antes das 18:00, após a inicialização novamente, o trabalho ainda estará aguardando a execução; se o tempo já tiver passado, o desligamento será realizado imediatamente, o que pode ser inesperado.
Outra diferença é que shutdown 18:00
criará um /run/nologin
arquivo 5 minutos antes da hora agendada para impedir que as pessoas efetuem login após esse momento. As mensagens de difusão também serão enviadas para avisar aos usuários conectados que o sistema está prestes a ser desligado.
Você precisa levar em conta essas diferenças para decidir qual usar.
nohup
ou o que disown
quer que seja, se o logout normalmente mata processos em execução em segundo plano. Sistemas diferentes podem ter padrões diferentes para isso. (Estou supondo que ainda exista um sudo shutdown
processo em execução, apenas sinalizando init
para iniciar um temporizador de desligamento. O último pode realmente ser o que acontece, mas não verifiquei recentemente. Ah, mas o @JdeBP tem; veja a resposta )
at
para que funcione via em cron
vez de atd
?
Se você possui o CentOS 7, possui um sistema operacional systemd e a resposta é diferente.
at 18:00 shutdown now
ainda agenda pelo at
subsistema, mas esse shutdown
comando, assim como o que você chama diretamente shutdown 18:00
, é diferente. Na verdade, é o systemctl
programa do systemd . systemctl
faz as coisas de maneira diferente.
Antes de tudo, systemctl
envia a solicitação de desligamento agendado para ser processada por um daemon, praticamente como no at
caso. Este é um daemon do systemd, no entanto, especificamente logind
(o systemd-shutdownd
daemon foi removido do systemd em maio de 2015, cuja alteração já percorreu as versões menores posteriores do CentOS 7), não o at
subsistema. systemctl
comunica um protocolo interno a um intermediário de barramento de desktop (em todo o sistema) que, por sua vez, se comunica logind
.
Assim, como no at
caso, não há shutdown
processo parado, contando e gerando as wall
mensagens. Portanto, é possível efetuar logout e isso não afetará o agendamento, e o cancelamento não é tão simples como simplesmente interromper / interromper o processo de primeiro plano da sessão de logon. Assim como com at
.
Ainda existem mensagens, diferentemente do at
caso, mas são emitidas por logind
. Diferentemente do at
caso, o trabalho agendado não persiste nas reinicializações do sistema; portanto, um desligamento real cancela um agendado. Não é um arquivo no sistema de arquivos, mas está sob /run/systemd/shutdown
o qual é o armazenamento não-persistente.
Outras diferenças são que pode haver apenas um desligamento agendado por vez, enquanto é possível enviar vários at
trabalhos, e o Policy Kit aplicará regras a serem shutdown
executadas no contexto de não sessão de login como um at
trabalho diferente das regras aplicadas na shutdown
execução. contexto da sessão de login. O último pode ser mais permissivo, permitindo (digamos) que um usuário sem privilégio conectado à sessão de logon ativo desligue o sistema.
shutdown 18:00
inicia um processo no seu shell que aguarda". E se você sair antes disso?