Como eu criaria um script que não respondesse a Ctrl-C ? Isso também deve impedir que quaisquer processos iniciados pelo script sejam mortos (estou tentando impedir que apt-get upgrade seja morto).
(Eu fiz algumas buscas na Internet, mas eu só encontrei perguntas sobre como matar processos desonestos.)
Contexto : estou criando VHDs mestre do Linux para um cluster de VM acadêmica. Quando uma máquina é criada, ela faz login como root no console e executa meu script, que atualizará a máquina, criará um novo usuário e ativará o SSH. Se alguém fizer login no console antes de concluir a atualização, eu quero impedir que ele cancele (acidentalmente ou intencionalmente) o processo de atualização com Ctrl-C .
Defina o sinal INT a ser ignorado:
trap '' INT
Isso causará o SIGINT, que é o que o Ctrl-C envia, para não fazer nada em seu script.
As conseqüências da experiência do usuário ao fazer isso são um pouco incertas para mim; isso pode ser irritante se o script ficar preso em uma operação que leva muito tempo para ser concluída. Pode ser melhor avisar o usuário que o script não deve (e não pode ser facilmente) interrompido antes de ignorar o sinal.
Com um script em perl, é tão fácil quanto:
#!/usr/bin/perl
use strict;
use warnings;
$SIG{'INT'} = "IGNORE";
#do stuff.
Eu sugeriria, porém, em vez de um script - você considerou um trabalho 'at'?
echo "sudo apt-get upgrade >> /tmp/upgrade.log" | at now
Qual será o início como tarefa no agendador.
Por que você não executa seu programa como um trabalho em segundo plano, portanto, não há terminal para emitir a interrupção ctrl + c .
Em seguida, a única maneira de eliminar o processo é emitindo sudo kill PID , o que exigiria privilégios de root. Mas se a pessoa tem privilégios de root do que você está apenas sem sorte na minha opinião ... Se eles têm raiz e querem terminar o processo eles vão ...
Depende de como e como você o constrói.
Embora o trapping possa ser uma opção interessante, imagino que alguns ambientes possam fazer com que ele não funcione como esperado.
No Rails, por exemplo, resgatar Interrupt , bem como resgatar Exception (Qual Interrupt estende) fará com que o programa se comporte "anormalmente" nos sinais de interrupção. No Java, capturar Throwable tem um comportamento similar.
Interceptar o sinal de interrupção pode ser uma boa opção, mas você deve considerar quando iniciar e quando interromper o trapping, o que pode acontecer entre e como o seu aplicativo responderá a esse "trapping" (ou seja, sua aplicação morrer de qualquer maneira ou lançar uma exceção ou algum outro erro? Ele ignorará seu aplicativo, mas ainda matará o apt-get? e assim por diante).
Além disso, kill pid pode causar um comportamento diferente e, até onde eu sei, kill -9 pid vai acabar com o seu processo, não importa o que você faça. Eu consideraria executá-lo como um trabalho em segundo plano que salva em um arquivo e monitorar o arquivo para alterações até que a atualização seja concluída (talvez até mesmo mostrá-lo na tela), possivelmente durante o salvamento / captura / etc SIGINTs. Eu também possivelmente verificaria algo como definir nível de execução ou algo assim para evitar um simples kill pid , já que a necessidade de um kill -9 pid pode evitar erros honestos.
Tags signals shell-script