Este log indica que o servidor foi reinicializado?

Question

Eu tenho um servidor web que acho que reiniciei em algum momento ... principalmente porque o apache não estava servindo sites e geralmente faz isso quando alguém o inicia e não digita a senha do certificado SSL ... e um reboot / start corrigido o problema. Olhando em volta em /var/log/messages , as primeiras entradas de log de hoje são:

Jun 30 05:17:40 localhost kernel: imklog 4.2.0, log source = /proc/kmsg started.
Jun 30 05:17:40 localhost rsyslogd: [origin software="rsyslogd" swVersion="4.2.0" x-pid="393" x-info="http://www.rsyslog.com"] (re)start
Jun 30 05:17:40 localhost rsyslogd: rsyslogd's groupid changed to 103
Jun 30 05:17:40 localhost rsyslogd: rsyslogd's userid changed to 101

Estou assumindo que isso significa que foi uma reinicialização, mas sei tão pouco sobre a administração real do servidor, queria verificar isso. Eu posso postar o resto de messages se isso for útil. A entrada anterior a estes, foi a seguinte uma vez por dia:

Jun 29 06:34:11 localhost rsyslogd: [origin software="rsyslogd" swVersion="4.2.0" x-pid="350" x-info="http://www.rsyslog.com"] rsyslogd was HUPed, type 'lightweight'.

Então, isso indica uma reinicialização do servidor, como eu estou supondo? Existe alguma maneira de determinar o que causou a reinicialização? Ou se uma pessoa fez isso?

    

Answer 1

A maneira mais fácil de ver se foi reinicializada recentemente é apenas digitar

uptime

Se você quiser verificar reinicializações intencionais, digite

lastlog

Se não houver registro de uma reinicialização deliberada ou de um pressionamento de botão liga / desliga, mesmo que tenha sido reiniciado, será necessário iniciar um procedimento de diagnóstico padrão para descobrir por que ele foi reiniciado. Comece olhando os gráficos do servidor para memória sobre alocação ou superaquecimento. Existem algumas coisas que podem causar reinicializações aleatórias que não serão registradas (kernel panic, watchdog etc.) - mas o registro remotamente do console serial fornecerá informações vitais.

    

Answer 2

O "rsyslogd foi HUPed" indica que o processo rsyslog foi reiniciado, e é a última mensagem porque presumivelmente não estava funcionando antes, e rsyslog é o processo que normalmente deixaria mensagens no log. Então, quando ele é reiniciado, as mensagens são reiniciadas.

Isto está possivelmente relacionado a um bug conhecido do Ubuntu, você pode ler mais sobre isso aqui link

Apesar de nada sugerir como curá-lo. É bem possível que o problema do rsyslog não esteja relacionado à reinicialização do servidor.

    

Answer 3

Pode indicar uma reinicialização. Pelo que você nos deu, eu realmente não posso dizer. Os logs que você postou indicam que o processo rsyslogd foi reiniciado (a partir de um sinal HUP). Eu não posso dizer se uma pessoa fez isso ou um programa fez isso porque ambos podem enviar um sinal HUP com as permissões corretas.

    

Answer 4

uptime mostrará quanto tempo passou desde a última reinicialização.

last mostrará os últimos usuários conectados e também mostrará se ele detecta uma solicitação de reinicialização regular.

quem mostrará quem está conectado agora. Certifique-se de que você é o único que está conectado ou que pode contabilizar todas as conexões.

Mais importantes são as linhas anteriores à linha do syslog. Pode nos dar algo, e talvez não. Entre em contato com quem estiver hospedando seu servidor e veja se ele teve algum tipo de interrupção de energia programada ou não programada ou reinicialize. A coisa mais preocupante não é que o servidor foi reinicializado, mas foi feito sem o seu conhecimento. Observe também que o hardware escasso ou com falha pode, às vezes, ser reinicializado por conta própria. Por isso, entre em contato com o provedor de hospedagem para descobrir se ele fez ou detectou algo que deve ser o primeiro passo.

    

Answer 5

Esse é exatamente o log que vejo quando meu sistema é iniciado.

# cat /etc/redhat-release
CentOS release 6.4 (Final)
# cat /var/log/messages
Aug 19 12:04:22 [...] kernel: imklog 5.8.10, log source = /proc/kmsg started
[...]
Aug 19 11:49:17 [...] ntpd[935]: 0.0.0.0 c61c 0c clock_step -913.885823 s

Observe que o ntpd pode alterar a hora e isso pode alterar os resultados de uptime . Por alguma razão, o meu está reportando 40 minutos a menos do que o valor real, mesmo que o ntpd só possa responder por 15 minutos da diferença.