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

Question

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 a partir do console, ou alguém bateu o botão liga / desliga, etc.?

    

Answer 1

Somente programas com privilégios de root podem desligar o sistema normalmente. Portanto, quando um sistema é desligado de maneira normal, ele é um usuário com privilégios de root ou um script acpi. Em ambos os casos, você pode descobrir marcando os registros. Um desligamento de acpi pode ser causado por pressionamento do botão liga / desliga, superaquecimento ou bateria fraca (laptop). Esqueci o terceiro motivo, o software da UPS quando a fonte de alimentação falha, o que enviará um alerta de qualquer maneira.

Recentemente eu tive um sistema que começou repetidamente a desligar, o superaquecimento e a mobo foi configurada para ser desligada cedo. O sistema não teve a chance de salvar os logs, mas felizmente a monitoração da temperatura do sistema mostrou que ele estava começando a aumentar antes de desligar.

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

    

Answer 2

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 saberá da próxima vez.

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

Como descobrir quem ou o que parou meu sistema

    

Answer 3

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

Mais uma vez, esses arquivos de log estão presentes em um sistema Ubuntu, portanto, nomes de arquivos podem ser diferentes. O comando tail é seu amigo.

    

Answer 4

Simplifique usando last exibindo as entradas de desligamento do sistema e execute alterações de nível e filtragem em shutdown e reboot :

last -x shutdown reboot

    

Answer 5

Não satisfaz plenamente

Eu tive uma necessidade semelhante em um Debian 7.8 e observei que basicamente não existe uma mensagem clara e explícita no log, o que é um pouco surpreendente.

O grep até /var/log informa a hora em que a máquina foi desligada, mostra o desligamento correto 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.

Olhando como funciona

Lendo /etc/acpi/powerbtn-acpi-support.sh , o que inclui:

if [ -x /etc/acpi/powerbtn.sh ] ; then
    # Compatibility with old config script from acpid package
    /etc/acpi/powerbtn.sh
elif [ -x /etc/acpi/powerbtn.sh.dpkg-bak ] ; then
        # Compatibility with old config script from acpid package
    # which is still around because it was changed by the admin
        /etc/acpi/powerbtn.sh.dpkg-bak
else
    # Normal handling.
    /sbin/shutdown -h -P now "Power button pressed"
fi

Observe que um texto explícito é fornecido como parâmetro do comando shutdown . Espero que essa cadeia seja registrada automaticamente pelo programa de desligamento.

Ajustando para melhores registros

De qualquer forma, para obter uma mensagem explícita, coloco o texto abaixo (como root) em um executável /etc/acpi/powerbtn.sh feito recentemente com chmod a+x /etc/acpi/powerbtn.sh

#!/bin/sh
logger in /etc/acpi/powerbtn.sh, presumably "Power button pressed"
    /sbin/shutdown -h -P now "Power button pressed"

Fazer isso desta maneira provavelmente fará uma mudança mais duradoura do que modificar /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 isso de forma diferente ( /etc/acpi/powerbtn.sh já existe com conteúdo diferente de acpid package). Além disso, o Debian 8 provavelmente faz isso de forma diferente. Sinta-se à vontade para oferecer variantes.

Lucro!

E agora, quando o botão liga / desliga é pressionado, uma linha como a abaixo aparece em /var/log/messages , /var/log/syslog e /var/log/user.log :

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

Agora, essa é uma mensagem explícita no log.

    

Answer 6

Existem 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 normais de desligamento

Um desligamento normal e ativação aparecem assim (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 (note que não há nenhuma 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 desligamentos inesperados

Um desligamento inesperado da perda de energia é assim (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 ocorre um desligamento inesperado ou uma falha de hardware, os sistemas de arquivos não serão devidamente desmontados. Assim, na próxima inicialização, você pode 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 é desligado porque o usuário pressionou o botão liga / desliga, você obtém registros como este:

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

Somente quando o sistema é desligado, você obtém registros 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ê tem um no-break e executa um daemon para monitorar a energia e o desligamento, obviamente deve verificar seus logs (o NUT registra em / var / log / messages mas o apcupsd registra em / var / log / apcupsd *)

Notas

*: Aqui está a descrição de last da sua 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 head para manter os últimos 10 eventos e usamos tac para inverter a ordenação, para que não nos confundamos com o fato de as últimas impressões do evento mais recente para o mais recente.

    

Answer 7

Eu tenho apenas uma ideia desajeitada, mas talvez funcione para você: insira o comando last e confira as informações de login para todos os usuários. em seguida, filtre os usuários com a permissão necessária para halt que estava conectada naquele momento. em seguida, confira o arquivo .bash_history para ver se eles entraram ou não.

    

Answer 8

No meu caso eu tive um problema de superaquecimento e encontrei o log em / 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

    

Answer 9

Apenas insira isso em minha KVM VM (onde me perguntei se uma reinicialização do host fez um desligamento limpo dos convidados), encontrei o que eu precisava em /var/log/auth.log (além de last -x shutdown mostrando 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 -x mostra essas linhas, observe que elas estão sendo impressas na ordem mais recente-primeiro (ou seja, leia a última linha primeiro e depois suba), mas devido ao relógio reset (23:56 antes do boot, 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)

De minha parte, verificando se os hóspedes são limpos quando o host é inicializado, eu também poderia fazer login (ssh) em um dos convidados e ficar lá quando inicializo o host, obtendo essas 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.

    

Answer 10

alias o desligamento para um script
o script deve fornecer todos os parâmetros, etc para o executável do desligamento original
MAS: o script deve logar os que estão aqui

    

Answer 11

cat /usr/adm/syslog

no meu caso, foi o software de ups desligando o servidor.

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