Respuestas:
Solo los programas con privilegios de root pueden apagar un sistema con gracia. Entonces, cuando un sistema se apaga de manera normal, es un usuario con privilegios de root o un script acpi. En ambos casos, puede averiguarlo revisando los registros. Un apagado acpi puede ser causado por presionar el botón de encendido, sobrecalentamiento o batería baja (laptop). Olvidé la tercera razón, el software de UPS cuando falla la fuente de alimentación, que enviará una alerta de todos modos.
Recientemente tuve un sistema que comenzó a apagarse repetidamente sin gracia, resultó que se estaba sobrecalentando y el mobo estaba configurado para apagarse temprano. El sistema no tuvo la oportunidad de guardar registros, pero afortunadamente el monitoreo de la temperatura del sistema mostró que estaba comenzando a aumentar justo antes de apagarse.
Entonces, si es un apagado normal, se registrará, si es una intrusión ... buena suerte, y si es un apagado en frío, su mejor oportunidad para saber es controlar y monitorear su entorno.
Pruebe los siguientes comandos:
Mostrar la lista de las últimas entradas de reinicio:
last reboot | less
Mostrar la lista de las últimas entradas de apagado:
last -x | less
o más precisamente:
last -x | grep shutdown | less
Sin embargo, no sabrá quién lo hizo. Si desea saber quién lo hizo, deberá agregar un poco de código, lo que significa que lo sabrá la próxima vez.
He encontrado este recurso en línea. Te puede ser útil:
last -x shutdown
Hay un par de cosas para verificar:
Ejecute este comando * y compare el resultado con los siguientes ejemplos:
last -x | head | tac
Un apagado normal y encendido se ve así (tenga en cuenta que tiene un evento de apagado y luego un evento de arranque del 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)
En algunos casos, puede ver esto (tenga en cuenta que no hay una línea sobre el apagado, pero el sistema estaba en el nivel de ejecución 0, que es el "estado de detención"):
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)
Un apagado inesperado por pérdida de energía se ve así (tenga en cuenta que tiene un evento de arranque del sistema sin un evento de apagado del sistema anterior):
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)
Un comando bash para filtrar los mensajes de registro más interesantes es este:
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'
Cuando se produce un apagado inesperado o una falla de hardware, los sistemas de archivos no se desmontarán correctamente, por lo que en el próximo arranque puede obtener registros 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.
Cuando el sistema se apaga porque el usuario presionó el botón de encendido, obtiene registros como este:
systemd-logind: Power key pressed.
systemd-logind: Powering Off...
systemd-logind: System is powering down.
Solo cuando el sistema se apaga ordenadamente, obtiene registros como este:
rsyslogd: ... exiting on signal 15
Cuando el sistema se apaga debido al sobrecalentamiento, obtiene registros como este:
critical temperature reached...,shutting down
Si tiene un UPS y ejecuta un demonio para monitorear la energía y el apagado, obviamente debe verificar sus registros (NUT inicia sesión en / var / log / messages pero apcupsd inicia sesión en / var / log / apcupsd *)
Notas
*: Aquí está la descripción de lastsu 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 mantener los últimos 10 eventos y usamos tacpara invertir el orden para que no nos confundamos con el hecho de que se imprime desde el evento más reciente hasta el menos reciente.
taccomando
Algunos posibles archivos de registro para explorar: (encontré un sistema Ubuntu, pero espero que estén presentes en la mayoría de los 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
Nuevamente, estos archivos de registro están presentes en un sistema Ubuntu, por lo que los nombres de los archivos pueden ser diferentes. El tailcomando es tu amigo.
Simplifique usando la lastvisualización de las entradas de apagado del sistema y ejecute cambios de nivel y filtrado en shutdowny reboot:
last -x shutdown reboot
cat foo | grep barvs grep bar footipo de camino, parece que la última es capaz de filtrar en sí.
Tenía una necesidad similar en un Debian 7.8 y observo que básicamente no hay un mensaje claro y explícito en el registro, lo cual es un poco sorprendente.
Grep through /var/logdiría la hora en que se apagó la máquina, mostraría el apagado adecuado de los demonios, etc., pero no la razón inicial.
shutdown[25861]: shutting down for system halt
Las otras soluciones mencionadas ( last -x) no ayudaron mucho.
Lectura /etc/acpi/powerbtn-acpi-support.shque incluye:
si [-x /etc/acpi/powerbtn.sh]; entonces
# Compatibilidad con el antiguo script de configuración del paquete acpid
/etc/acpi/powerbtn.sh
elif [-x /etc/acpi/powerbtn.sh.dpkg-bak]; entonces
# Compatibilidad con el antiguo script de configuración del paquete acpid
# que todavía existe porque fue cambiado por el administrador
/etc/acpi/powerbtn.sh.dpkg-bak
más
# Manejo normal.
/ sbin / shutdown -h -P ahora "Botón de encendido presionado"
fi
Observe que se proporciona un texto explícito como parámetro del shutdowncomando. Esperaría que la cadena sea registrada automáticamente por el programa de apagado.
De todos modos, para obtener un mensaje explícito pongo el texto a continuación (como root) en un /etc/acpi/powerbtn.shejecutable creado recientemente conchmod a+x /etc/acpi/powerbtn.sh
#! / bin / sh
registrador en /etc/acpi/powerbtn.sh, presumiblemente "botón de encendido presionado"
/ sbin / shutdown -h -P ahora "Botón de encendido presionado"
Hacerlo de esta manera probablemente hará un cambio más duradero que la modificación /etc/acpi/powerbtn-acpi-support.sh. La última opción probablemente perdería su efecto en la próxima actualización del paquete acpi-support-base.
Tenga en cuenta que Ubuntu 14.04 lo hace de manera diferente ( /etc/acpi/powerbtn.shya existe con diferente contenido del acpidpaquete). Además, Debian 8 probablemente lo hace de manera diferente. Siéntase libre de ofrecer variantes.
Y ahora, cuando se presiona el botón de encendido, aparece una línea como la siguiente /var/log/messages, /var/log/syslogy /var/log/user.log:
logger: in /etc/acpi/powerbtn.sh, presumably Power button pressed
Ahora ese es un mensaje explícito en el registro.
acpi-support-basey los acpidpaquetes. No me he probado a mí mismo. ¿Puede explicar en qué distribución y versión produce beneficios?
Tengo una idea torpe, pero tal vez funcione para usted: ingrese el comando lasty revise la información de inicio de sesión para todos los usuarios. luego, filtre a los usuarios con el permiso requerido para haltque haya iniciado sesión en ese momento. luego revise su .bash_historyarchivo para ver si han entrado en alto o no.
En mi caso tuve un problema de sobrecalentamiento y encontré el inicio de sesión en / var / log / syslog por un 'grep shut *' en la carpeta / var / log.
El error registrado fue este:
Feb 23 15:59:49 luca-LIFEBOOK-A530 kernel: [24746.497174] thermal thermal_zone0: critical temperature reached(99 C),shutting down
Simplemente agregue eso en mi VM KVM (donde me preguntaba si un reinicio del host hizo un apagado limpio de los invitados), encontré lo que necesitaba /var/log/auth.log(además de last -x shutdownmostrar lo mismo). Allí aparecieron estas líneas:
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 -xmuestra estas líneas, observe que se imprimen en el primer orden más reciente (es decir, lea primero la última línea y luego suba), pero debido al reinicio del reloj (23:56 antes del arranque, 23:55 después) También evidente en las líneas anteriores, el orden parece un poco 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)
Por mi parte, verificando que los invitados se apaguen limpiamente cuando se inicia el host, también podría iniciar sesión (ssh) en uno de los invitados y permanecer allí cuando arranque el host, obteniendo estas líneas en la 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.
alias el apagado a un script,
el script debe proporcionar todos los parámetros, etc., al ejecutable de apagado original
PERO: el script debe registrarlos.
last -x)
cat /usr/adm/syslog
en mi caso fue el software ups que apaga el servidor.
/etc/rc.d/7/upsd.boot
/var/log/acpid: resultó que el botón de encendido fue golpeado. ¿Alguna otra idea, dónde buscar si acpid no da una pista?