Mientras investigaba un servidor que se reiniciaba regularmente, comencé a buscar en la "última" utilidad, pero el problema es que no puedo encontrar qué significan exactamente las columnas. Por supuesto, he revisado al hombre, pero no contiene esta información.
root@webservice1:/etc# last reboot
reboot system boot 3.2.13-grsec-xxx Thu Apr 12 09:44 - 09:58 (00:13)
reboot system boot 3.2.13-grsec-xxx Thu Apr 12 09:34 - 09:43 (00:08)
reboot system boot 3.2.13-grsec-xxx Thu Apr 12 09:19 - 09:33 (00:13)
reboot system boot 3.2.13-grsec-xxx Thu Apr 12 08:51 - 09:17 (00:25)
reboot system boot 3.2.13-grsec-xxx Thu Apr 12 00:11 - 09:17 (09:05)
reboot system boot 3.2.13-grsec-xxx Wed Apr 11 19:40 - 09:17 (13:36)
reboot system boot 3.2.13-grsec-xxx Sun Apr 8 22:06 - 09:17 (3+11:10)
reboot system boot 3.2.13-grsec-xxx Sat Apr 7 14:31 - 09:17 (4+18:45)
reboot system boot 3.2.13-grsec-xxx Fri Apr 6 10:20 - 09:17 (5+22:56)
reboot system boot 3.2.13-grsec-xxx Thu Apr 5 00:16 - 09:17 (7+09:01)
reboot system boot 3.2.13-grsec-xxx Tue Apr 3 07:34 - 09:17 (9+01:42)
reboot system boot 3.2.13-grsec-xxx Tue Apr 3 02:31 - 09:17 (9+06:45)
reboot system boot 3.2.13-grsec-xxx Mon Apr 2 23:17 - 09:17 (9+09:59)
Las primeras columnas tienen sentido hasta las versiones del kernel incluidas. ¿Qué representan estos tiempos exactamente? El último parece ser el tiempo de actividad.
En segundo lugar, se supone que este es un servidor que funciona 24 horas al día, 7 días a la semana, excepto que los tiempos no parecen coincidir, lo que podría significar que está experimentando un tiempo de inactividad o algo similar. Por ejemplo, si miramos las dos últimas líneas, ¿significa que mi servidor estuvo apagado desde el 2 de abril a las 09:17 hasta el 3 de abril a las 02:31?
En cuanto a la información general, este es un servidor Debian Squeeze.
EDITAR
Si las últimas columnas son hora de inicio, hora de finalización y tiempo de actividad, ¿cómo se pueden interpretar estas dos líneas?
reboot system boot 3.2.13-grsec-xxx Tue Apr 3 07:34 - 09:17 (9+01:42)
reboot system boot 3.2.13-grsec-xxx Tue Apr 3 02:31 - 09:17 (9+06:45)
La segunda sesión parece terminar después de que comienza la primera, lo cual no tiene sentido para mí.
Respuesta1
Supongo que esta es una publicación de hace tres años, pero responderé de todos modos, para beneficio de cualquiera que se encuentre con ella en el futuro, como lo hice yo recientemente.
Al leer otras publicaciones y monitorear el resultado durante un período de tiempo, parece que cada línea enumera la fecha y hora de inicio de la sesión, la hora de finalización de la sesión (pero no la fecha de finalización) y la duración de la sesión. (cuánto tiempo estuvieron conectados) en un formato como
(días+horas:minutos)
Parece que se indica que el usuario de reinicio inició sesión cada vez que se inicia el sistema y se apagó cuando el sistema se reinició o apagó, y en esas líneas, la información de "duración de la sesión" es el período de tiempo (días+horas:minutos) Esa "sesión" duró, es decir, cuánto tiempo estuvo activo el sistema antes de apagarse.
Para mí, la entrada de reinicio más reciente muestra la hora actual como la hora de "desconexión", y los datos de duración de la sesión para esa entrada coinciden con el resultado del tiempo de actividad actual.
Entonces en esta línea:
reiniciar el sistema de arranque 3.2.13-grsec-xxx martes 3 de abril 07:34 - 09:17 (9+01:42)
El sistema se puso en marcha el martes 3 de abril a las 7:34 am y se apagó 9 días y 1 hora y 42 minutos después (el día 12 de abril), a las 9:17 de la mañana. (O bien, este resultado se recopiló en ese momento, y esta es la entrada de reinicio más reciente, y "reiniciar" en realidad aún no se ha "desconectado". En cuyo caso el resultado cambiará si ejecuta el último comando nuevamente).
Para mí es un misterio por qué tendría 2 entradas para el usuario reiniciado, el 3 de abril, que duraron 9 días; Mis sistemas no hacen eso.
Respuesta2
Resumen
- La primera marca de tiempo parece ser la hora en que el sistema dejó de funcionar durante el reinicio.
- La segunda marca de tiempo y el tiempo transcurrido no son muy útiles.
- Pasar la
-xopción alastpuede resultar útil para mostrar otros eventos relacionados con apagados y cambios de nivel de ejecución que influyen en las marcas de tiempo que se muestran en lasrebootlíneas. Latuptimeherramienta a la que se hace referencia en otra respuesta puede aclarar esto, pero no la he mirado.
Detalles
La lastpágina de manual en CentOS 6 y 7 dice:
El reinicio del pseudousuario se registra cada vez que se reinicia el sistema.
No dice nada sobre cuándo el usuario cierra la sesión, y la evidencia que se muestra a continuación parece sugerir que no se registra explícitamente ninguna hora de cierre de sesión. Las páginas de manual rebooty shutdowntienen más detalles sobre cómo registrar los cambios en el nivel de ejecución si alguien está interesado.
De las pruebas, parece que el tiempo de inicio de sesión es desde el final del proceso de apagado; no es desde el momento en que rebootse emitió el comando.
Por lo tanto, parecería que las horas de cierre de sesión (la segunda marca de tiempo) y la duración durante la cual se inició sesión en "reinicio" (que se muestra entre paréntesis) probablemente deberían ignorarse.
Si pasa la -Fopción a last, le mostrará las marcas de tiempo completas, lo que deja un poco más claro que la máquina no se reinicia coincidentemente al mismo tiempo, solo muestra exactamente la misma marca de tiempo varias veces. Además, si pasa la -xbandera, muestra "entradas de apagado del sistema y cambios de nivel de ejecución".
Aquí, lo ejecuté en CentOS 7 y también pasé la -Ropción para suprimir la columna nombre de host/versión del kernel. También eliminé algunos inicios de sesión de root poco interesantes:
# date ; last -x -F -R
Mon Nov 12 01:10:44 UTC 2018
root pts/0 Mon Nov 12 00:02:57 2018 still logged in
runlevel (to lvl 3) Sat Nov 10 17:57:29 2018 - Mon Nov 12 01:10:44 2018 (1+07:13)
reboot system boot Sat Nov 10 17:57:12 2018 - Mon Nov 12 01:10:44 2018 (1+07:13)
runlevel (to lvl 3) Sat Oct 27 17:58:20 2018 - Sat Nov 10 17:57:29 2018 (13+23:59)
reboot system boot Sat Oct 27 17:58:03 2018 - Mon Nov 12 01:10:44 2018 (15+07:12)
runlevel (to lvl 3) Sat Jul 21 18:14:55 2018 - Sat Oct 27 17:58:20 2018 (97+23:43)
reboot system boot Sat Jul 21 18:14:16 2018 - Mon Nov 12 01:10:44 2018 (113+06:56)
runlevel (to lvl 3) Sun Nov 12 22:36:14 2017 - Sat Jul 21 18:14:55 2018 (250+19:38)
reboot system boot Sun Nov 12 22:35:35 2017 - Mon Nov 12 01:10:44 2018 (364+02:35)
root pts/0 Fri Nov 10 07:13:20 2017 - crash (2+15:22)
runlevel (to lvl 3) Sun Aug 27 04:15:56 2017 - Sun Nov 12 22:36:14 2017 (77+18:20)
reboot system boot Sun Aug 27 04:14:59 2017 - Mon Nov 12 01:10:44 2018 (441+20:55)
runlevel (to lvl 3) Mon Aug 14 00:14:01 2017 - Sun Aug 27 04:15:56 2017 (13+04:01)
reboot system boot Mon Aug 14 00:13:46 2017 - Mon Nov 12 01:10:44 2018 (455+00:56)
Las 6 líneas de "reinicio" anteriores tienen un tiempo de cierre de sesión igual al tiempo actual.
shutdown system down Fri Aug 11 08:05:29 2017 - Mon Aug 14 00:13:46 2017 (2+16:08)
root pts/0 Fri Aug 11 08:05:23 2017 - down (00:00)
runlevel (to lvl 3) Fri Jun 30 07:05:42 2017 - Fri Aug 11 08:05:29 2017 (42+00:59)
reboot system boot Fri Jun 30 07:05:27 2017 - Fri Aug 11 08:05:29 2017 (42+01:00)
[...]
root pts/0 Fri Jun 30 05:48:16 2017 - crash (01:17)
root pts/0 Tue Jun 27 04:59:56 2017 - Tue Jun 27 05:00:30 2017 (00:00)
root pts/0 Mon Jun 26 11:20:57 2017 - Mon Jun 26 04:24:39 2017 (-6:-56)
runlevel (to lvl 3) Mon Jun 26 11:15:13 2017 - Fri Jun 30 07:05:42 2017 (3+19:50)
reboot system boot Mon Jun 26 11:14:57 2017 - Fri Aug 11 08:05:29 2017 (45+20:50)
root pts/0 Sun Jun 25 14:07:51 2017 - crash (21:07)
[...]
root tty1 Thu Jun 22 13:07:42 2017 - crash (3+22:07)
runlevel (to lvl 3) Thu Jun 22 13:07:07 2017 - Mon Jun 26 11:15:13 2017 (3+22:08)
reboot system boot Thu Jun 22 13:06:51 2017 - Fri Aug 11 08:05:29 2017 (49+18:58)
root pts/0 Thu Jun 22 12:43:56 2017 - crash (00:22)
runlevel (to lvl 3) Thu Jun 22 12:30:53 2017 - Thu Jun 22 13:07:07 2017 (00:36)
reboot system boot Thu Jun 22 12:30:38 2017 - Fri Aug 11 08:05:29 2017 (49+19:34)
root pts/1 Thu Jun 22 12:26:49 2017 - crash (00:03)
root pts/0 Thu Jun 22 11:55:28 2017 - crash (00:35)
runlevel (to lvl 3) Thu Jun 22 11:49:53 2017 - Thu Jun 22 12:30:53 2017 (00:41)
reboot system boot Thu Jun 22 11:49:14 2017 - Fri Aug 11 08:05:29 2017 (49+20:16)
Las 5 líneas de "reinicio" anteriores tienen un tiempo de cierre de sesión igual al tiempo del "apagado del sistema" que les siguió.
shutdown system down Thu Jun 22 11:47:45 2017 - Thu Jun 22 11:49:14 2017 (00:01)
[...]
runlevel (to lvl 3) Wed Jun 21 15:59:42 2017 - Thu Jun 22 11:47:45 2017 (19:48)
reboot system boot Wed Jun 21 15:59:27 2017 - Thu Jun 22 11:47:45 2017 (19:48)
El tiempo de cierre de sesión de "reinicio" coincide nuevamente con el tiempo de "apagado del sistema".
shutdown system down Wed Jun 21 15:57:58 2017 - Wed Jun 21 15:59:27 2017 (00:01)
root pts/0 Wed Jun 21 14:27:43 2017 - down (01:30)
[...]
runlevel (to lvl 3) Tue Jun 20 17:14:15 2017 - Wed Jun 21 15:57:58 2017 (22:43)
reboot system boot Tue Jun 20 17:14:00 2017 - Wed Jun 21 15:57:58 2017 (22:43)
Como anteriormente.
A partir de los resultados anteriores, asumo que no se registra ningún tiempo de cierre de sesión explícito para el "reinicio" del pseudousuario, por lo que lastle asigna un tiempo de cierre de sesión del siguiente "arranque del sistema de apagado", o la hora actual si no hay un "arranque del sistema de apagado". " siguiéndolo.
Las entradas de "nivel de ejecución (a nivel 3)" parecen tener un tiempo de cierre de sesión más sensato, pero no parece tener en cuenta los bloqueos.
Respuesta3
Desde la página de manual, las últimas columnas parecen ser el inicio de la sesión, los tiempos de finalización y la duración de la sesión.
Respuesta4
El último tiempo de actividad de la línea como usted dice. Creo que la hora de reinicio de las últimas dos columnas y la hora actual. Porque cuando ejecuto el último comando, la segunda columna desde atrás muestra la hora actual y siempre cambia.