Significados de las columnas en el comando "último"

Mientras investigaba un servidor que se reiniciaba de manera regular, comencé a buscar la "última" utilidad, pero el problema es que no puedo encontrar el significado exacto de las columnas. Por supuesto, he examinado 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 núcleo incluidas. ¿Qué representan exactamente estos tiempos? El último parece ser el tiempo de actividad.

En segundo lugar, se supone que este es un servidor 24/7, 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 de fondo, 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 puede 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 que no tiene sentido para mí.

Supongo que esta es una publicación de tres años, pero responderé de todos modos, en beneficio de cualquier otra persona que se encuentre en el futuro, como lo hice recientemente.

Al leer otras publicaciones y monitorear la salida yo mismo 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 el usuario de reinicio parece haber iniciado sesión cada vez que se inicia el sistema y se apaga cuando el sistema se reinicia o se apaga, 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 "desconectada", y los datos de duración de la sesión para esa entrada coinciden con la salida de tiempo de actividad actual.

Entonces en esta línea:

reiniciar el arranque del sistema 3.2.13-grsec-xxx Mar 3 Abr 07:34 - 09:17 (9 + 01: 42)

El sistema se inició el martes 3 de abril a las 7:34 a.m. y se cerró 9 días y 1 hora y 42 minutos después (el 12 de abril) a las 9:17 de la mañana. (O bien, esta salida se recopiló en ese momento, y esta es la entrada de reinicio más reciente, y "reiniciar" aún no se ha "desconectado" todavía. En ese caso, la salida cambiará si ejecuta el último comando nuevamente).

Por qué tendría 2 entradas para el usuario de reinicio, el 3 de abril, que duraron 9 días, es un misterio para mí; Mis sistemas no hacen eso.

Resumen

• La primera marca de tiempo parece ser la hora en que el sistema se apagó durante el reinicio.
• La segunda marca de tiempo y el tiempo transcurrido no son muy útiles.
• Pasar la -xopción a lastpuede ser útil para mostrar otros eventos relacionados con paradas y ejecutar cambios de nivel que influyen en las marcas de tiempo que se muestran en las rebootlíneas. La tuptimeherramienta a la que se hace referencia en otra respuesta puede aclarar esto, pero no la he mirado.

Detalles

La lastpágina del manual en CentOS 6 y 7 dice:

El reinicio del pseudo usuario inicia sesión cada vez que se reinicia el sistema.

No dice nada acerca de cuándo el usuario cierra sesión, y la evidencia que se muestra a continuación parece sugerir que no se registra explícitamente ningún tiempo de cierre de sesión. Las páginas man rebooty shutdowntienen más detalles sobre cómo registrar los cambios en el nivel de ejecución si alguien está interesado.

Después de la prueba, parece que el tiempo de inicio de sesión es tardío en el proceso de apagado, no es desde el momento en que rebootse emitió el comando.

Por lo tanto, parece que los tiempos de cierre de sesión (la segunda marca de tiempo) y la duración durante la cual se inició el "reinicio" (que se muestra entre paréntesis) probablemente se deben ignorar.

Si pasa la -Fopción a last, le mostrará marcas de tiempo completas, lo que deja un poco más claro que la máquina no se reinicia por coincidencia al mismo tiempo, solo muestra 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 de suprimir la columna de versión de kernel / nombre de host. También eliminé algunos inicios de sesión raíz 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" 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" sobre todo 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.

Asumo por los resultados anteriores que no se registra un tiempo de cierre de sesión explícito para el "reinicio" del pseudo usuario, por lo que se le lastasigna un tiempo de cierre de sesión del próximo "inicio del sistema de apagado", o la hora actual si no hay un "inicio del sistema de apagado" "Siguiéndolo.

Las entradas "runlevel (to lvl 3)" parecen tener un tiempo de cierre de sesión más sensato, pero no parece tener en cuenta los bloqueos.

Desde la página de manual, las últimas columnas parecen ser el inicio de la sesión, los tiempos de parada y la duración de la sesión.

Estaba buscando cuando el servidor reiniciaba un servidor (una tarea programada para parchear las vulnerabilidades recientes de la CPU Meltdown y Spectre) y cuál era el tiempo de inactividad real de la operación.

Utilizo una alternativa al "último reinicio" porque siento que carece de claridad como ya lo notas.

Ejecutando tuptime -lpuedo ver la siguiente lista del comportamiento del sistema:

...
Startup:  26  at  06:51:32 AM 11/06/2017
Uptime:   72 days, 20 hours, 5 minutes and 15 seconds
Shutdown: OK  at  02:56:47 AM 01/18/2018
Downtime: 18 minutes and 44 seconds

Startup:  27  at  03:15:31 AM 01/18/2018
Uptime:   5 days, 7 hours, 11 minutes and 32 seconds

En el que está claro que el shudown se realizó siguiendo el procedimiento de apagado del sistema a la hora y fecha específicas "02:56:47 AM 18/01/2018". El tiempo de inactividad fue de "18 minutos y 44 segundos" y el inicio fue a las "03:15:31 AM 18/01/2018" y todavía se está ejecutando por ahora.

La última línea de tiempo de actividad como usted dice. El tiempo de reinicio de las dos últimas columnas y la hora actual, creo. Porque cuando ejecuto el último comando, la segunda columna desde atrás muestra la hora actual y siempre cambia.