- ssh morto por SIGTERM
- ssh fecha seu dispositivo mestre pseudo-terminal (pty)
- O pty envia SIGHUP para o bash.
- "O shell sai por padrão após o recebimento de um SIGHUP."
Eu fiz um trabalho remoto em uma máquina que tenho acesso pouco frequente e, no final da minha sessão, emiti sudo halt para encerrar a conexão e desligar a máquina. Infelizmente, agora não sei se os comandos que usei na sessão foram gravados no arquivo .bash_history . De acordo com man halt , ele envia todos os processos em execução a um SIGTERM e, em seguida, a um SIGKILL (suponho que ele faça isso apenas se o processo não morrer de maneira oportuna):
The halt and reboot utilities flush the file system cache to disk, send all running processes a SIGTERM (and subsequently a SIGKILL) and, respectively, halt or restart the system.
Eu testei isso na minha máquina pessoal enviando primeiro o SIGTERM para o bash, para o qual o bash parecia não responder. Então eu enviei um SIGKILL, que obviamente forçou a morte a morrer. Então, verifiquei o arquivo .bash_history para ver se havia algo escrito na minha sessão e nada estava. Isso faz sentido para mim, uma vez que, de acordo com o meu entendimento, o SIGTERM pode ser ignorado por um processo e pode executar seus procedimentos de desligamento como deseja, uma vez que ele pode interpretar como responder a esse sinal. No entanto, mais uma vez, de acordo com o meu próprio entendimento, o SIGKILL não pode ser ignorado e não concede o processo a qualquer momento para realizar limpezas ou outros rituais de morte.
De acordo com este teste e as conclusões a que cheguei deste teste, parece que é bastante improvável que minha sessão remota tenha sido salva quando emiti sudo halt no host remoto. Existe alguma maneira de eu estar errado sobre isso e que minha sessão remota foi salva em .bash_history ?
Tags bash shutdown command-history