Como descobrir nos logs o que causou o desligamento do sistema?

Por exemplo, estou vendo isso em /var/log/messages:

Mar 01 23:12:34 hostname shutdown: shutting down for system halt

Existe uma maneira de descobrir o que causou o desligamento? Por exemplo, foi executado no console ou alguém apertou o botão liga / desliga, etc.?

Somente programas com privilégios de root podem desligar um sistema normalmente. Portanto, quando um sistema é desligado de maneira normal, é um usuário com privilégios de root ou um script acpi. Nos dois casos, você pode descobrir verificando os logs. Um desligamento acpi pode ser causado por pressionar o botão liga / desliga, superaquecimento ou bateria fraca (laptop). Esqueci a terceira razão, o software UPS quando a fonte de alimentação falha, o que enviará um alerta de qualquer maneira.

Recentemente, eu tinha um sistema que começou a desligar repetidamente sem sucesso, resultou em superaquecimento e o mobo foi configurado para desligar cedo. O sistema não teve a chance de salvar logs, mas felizmente o monitoramento da temperatura do sistema mostrou que estava começando a aumentar pouco antes de desligar.

Portanto, se for um desligamento normal, será registrado, se for uma invasão ... boa sorte, e se for um desligamento a frio, sua melhor chance de saber é controlar e monitorar seu ambiente.

Experimente os seguintes comandos:

Exibir lista das últimas entradas de reinicialização: last reboot | less

Exibir lista das últimas entradas de desligamento: last -x | less

ou mais precisamente: last -x | grep shutdown | less

Você não saberá quem fez isso no entanto. Se você quiser saber quem fez isso, precisará adicionar um pouco de código, o que significa que você saberá na próxima vez.

Encontrei este recurso online. Pode ser útil para você:

Como descobrir quem ou o que interrompeu meu sistema

Há algumas coisas para verificar:

Verifique a saída do último comando -x

Execute este comando * e compare a saída com os exemplos abaixo:

last -x | head | tac

Exemplos de desligamento normal

Um desligamento e inicialização normais são parecidos com este (observe que você tem um evento de desligamento e, em seguida, um evento de inicialização do sistema):

runlevel (to lvl 0)   2.6.32- Sat Mar 17 08:48 - 08:51  (00:02) 
shutdown system down  ... <-- first the system shuts down   
reboot   system boot  ... <-- afterwards the system boots
runlevel (to lvl 3)       

Em alguns casos, você pode ver isso (observe que não há linha sobre o desligamento, mas o sistema estava no nível de execução 0, que é o "estado de parada"):

runlevel (to lvl 0)   ... <-- first the system shuts down (init level 0)
reboot   system boot  ... <-- afterwards the system boots
runlevel (to lvl 2)   2.6.24-... Fri Aug 10 15:58 - 15:32 (2+23:34)   

Exemplos de desligamento inesperado

Um encerramento inesperado por perda de energia é semelhante a este (observe que você tem um evento de inicialização do sistema sem um evento anterior de desligamento do sistema):

runlevel (to lvl 3)   ... <-- the system was running since this momemnt
reboot   system boot  ... <-- then we've a boot WITHOUT a prior shutdown
runlevel (to lvl 3)   3.10.0-693.21.1. Sun Jun 17 15:40 - 09:51  (18:11)    

Examine os logs em / var / log

Um comando bash para filtrar as mensagens de log mais interessantes é o seguinte:

grep -iv ': starting\|kernel: .*: Power Button\|watching system buttons\|Stopped Cleaning Up\|Started Crash recovery kernel' \
  /var/log/messages /var/log/syslog /var/log/apcupsd* \
  | grep -iw 'recover[a-z]*\|power[a-z]*\|shut[a-z ]*down\|rsyslogd\|ups'

Quando ocorrer um desligamento inesperado ou falha de hardware, os sistemas de arquivos não serão desmontados adequadamente; portanto, na próxima inicialização, você poderá obter logs como este:

EXT4-fs ... INFO: recovery required ... 
Starting XFS recovery filesystem ...
systemd-fsck: ... recovering journal
systemd-journald: File /var/log/journal/.../system.journal corrupted or uncleanly shut down, renaming and replacing.

Quando o sistema desliga porque o usuário pressionou o botão liga / desliga, você obtém logs como este:

systemd-logind: Power key pressed.
systemd-logind: Powering Off...
systemd-logind: System is powering down.

Somente quando o sistema é encerrado em ordem, você obtém logs como este:

rsyslogd: ... exiting on signal 15

Quando o sistema é desligado devido ao superaquecimento, você recebe logs como este:

critical temperature reached...,shutting down

Se você possui um no-break e está executando um daemon para monitorar a energia e o desligamento, obviamente deve verificar seus registros (o NUT registra / var / log / messages, mas o apcupsd registra / var / log / apcupsd *)

Notas

*: Aqui está a descrição da lastsua página de manual:

last [...] prints information about connect times of users. 
Records are printed from most recent to least recent.  
[...]
The special users reboot and shutdown log in when the system reboots
or (surprise) shuts down. 

Usamos headpara manter os 10 eventos mais recentes e tacinvertemos a ordem para não ficarmos confusos pelo fato de as últimas impressões do evento mais recente para o menos recente.

Alguns arquivos de log possíveis para explorar: (encontrei um sistema Ubuntu, mas espero que eles estejam presentes na maioria dos sistemas Linux / Unix)

/var/log/debug
/var/log/syslog (will be pretty full and may be harder to browse)
/var/log/user.log
/var/log/kern.log
/var/log/boot

Novamente, esses arquivos de log estão presentes em um sistema Ubuntu, portanto, os nomes de arquivos podem ser diferentes. O tailcomando é seu amigo.

Simplifique usando a lastexibição das entradas de desligamento do sistema e execute alterações de nível e filtragem shutdowne reboot:

last -x shutdown reboot

Não é totalmente satisfatório

Eu tinha uma necessidade semelhante no Debian 7.8 e observe que basicamente não há mensagens claras e explícitas no log, o que é um pouco surpreendente.

O Grep through /var/loginformaria a hora em que a máquina foi desligada, mostraria o desligamento adequado dos daemons etc., mas não o motivo inicial.

shutdown[25861]: shutting down for system halt

As outras soluções mencionadas ( last -x) não ajudaram muito.

Como funciona

Leitura /etc/acpi/powerbtn-acpi-support.shque inclui:

if [-x /etc/acpi/powerbtn.sh]; então
    # Compatibilidade com script de configuração antigo do pacote acpid
    /etc/acpi/powerbtn.sh
elif [-x /etc/acpi/powerbtn.sh.dpkg-bak]; então
        # Compatibilidade com script de configuração antigo do pacote acpid
    # que ainda existe porque foi alterado pelo administrador
        /etc/acpi/powerbtn.sh.dpkg-bak
outro
    # Manuseio normal.
    / sbin / shutdown -h -P now "Botão liga / desliga pressionado"
fi

Observe que um texto explícito é fornecido como parâmetro do shutdowncomando. Eu esperaria que essa string fosse registrada automaticamente pelo programa de desligamento.

Ajustando para melhores logs

De qualquer forma, para receber uma mensagem explícita, coloquei o texto abaixo (como root) em um /etc/acpi/powerbtn.shexecutável recém-criado comchmod a+x /etc/acpi/powerbtn.sh

#! / bin / sh
logger em /etc/acpi/powerbtn.sh, presumivelmente "Botão liga / desliga pressionado"
    / sbin / shutdown -h -P now "Botão liga / desliga pressionado"

Fazer dessa maneira provavelmente fará uma mudança mais duradoura que a modificação /etc/acpi/powerbtn-acpi-support.sh. A última opção provavelmente perderia seu efeito na próxima atualização do pacote acpi-support-base.

Observe que o Ubuntu 14.04 faz diferente ( /etc/acpi/powerbtn.shjá existe com conteúdo diferente do acpidpacote). Além disso, o Debian 8 provavelmente faz diferente. Sinta-se livre para oferecer variantes.

Lucro!

E agora, quando o botão de energia é pressionado, uma linha como abaixo aparece no /var/log/messages, /var/log/sysloge /var/log/user.log:

logger: in /etc/acpi/powerbtn.sh, presumably Power button pressed

Agora essa é uma mensagem explícita no log.

Tenho apenas uma ideia desajeitada, mas talvez funcione para você: insira o comando laste verifique as informações de login de todos os usuários. em seguida, filtre os usuários com a permissão necessária para haltefetuar o login naquele momento. então verifique o .bash_historyarquivo deles para ver se eles entraram ou não.

No meu caso, tive um problema de superaquecimento e encontrei o logon / var / log / syslog por um 'grep shut *' na pasta / var / log.

O erro registrado foi este:

Feb 23 15:59:49 luca-LIFEBOOK-A530 kernel: [24746.497174] thermal thermal_zone0: critical temperature reached(99 C),shutting down

Apenas inseri isso na minha VM KVM (onde eu me perguntava se uma reinicialização do host fazia um desligamento limpo dos convidados), encontrei o que precisava /var/log/auth.log(além de last -x shutdownmostrar o mesmo). Lá estas linhas apareceram:

Sep  3 23:56:31 Web systemd-logind[531]: Power key pressed.
Sep  3 23:56:31 Web systemd-logind[531]: Powering Off...
Sep  3 23:56:31 Web systemd-logind[531]: System is powering down.
Sep  3 23:55:45 Web systemd-logind[591]: New seat seat0.
Sep  3 23:55:45 Web systemd-logind[591]: Watching system buttons on /dev/input/event0 (Power Button)
Sep  3 23:55:54 Web sshd[805]: Server listening on 0.0.0.0 port 22.
Sep  3 23:55:54 Web sshd[805]: Server listening on :: port 22.

last -xmostra essas linhas, observe que elas estão sendo impressas na ordem mais recente (por exemplo, leia a última linha primeiro e depois suba), mas devido à redefinição do relógio (23:56 antes da inicialização, 23:55 depois) também evidente nas linhas anteriores, a ordem parece um pouco desconcertante:

runlevel (to lvl 2)   3.13.0-129-gener Sun Sep  3 23:55 - 22:04  (22:08)    
reboot   system boot  3.13.0-129-gener Sun Sep  3 23:55 - 22:04  (22:08)    
shutdown system down  3.13.0-123-gener Sun Sep  3 23:56 - 23:55  (00:00)    
runlevel (to lvl 0)   3.13.0-123-gener Sun Sep  3 23:56 - 23:56  (00:00)

Da minha parte, verificando se os convidados são desligados corretamente quando o host é inicializado, eu também poderia entrar (ssh) em um dos convidados e ficar lá quando eu inicializava o host, colocando estas linhas no terminal:

root@Web:~#
Broadcast message from root@Web
        (unknown) at 22:25 ...

The system is going down for power off NOW!
Connection to web closed by remote host.
Connection to web closed.

aliás, o desligamento de um script,
o script deve fornecer todos os parâmetros, etc. ao executável de desligamento original,
MAS: o script deve registrar aqueles

cat /usr/adm/syslog

no meu caso, foi o software de ups que desligou o servidor.

/etc/rc.d/7/upsd.boot