Significados das colunas no comando "last"

Como eu estava investigando um servidor que está sendo reinicializado regularmente, comecei a procurar o "último" utilitário, mas o problema é que não consigo encontrar exatamente o que as colunas significam. Obviamente, olhei através do homem, mas ele não contém essas informações.

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)   

As primeiras colunas fazem sentido até as versões do kernel incluídas. O que esses tempos representam exatamente? O último parece ser o tempo de atividade.

Em segundo lugar, é suposto ser um servidor 24 horas por dia, 7 dias por semana, exceto que os horários não parecem coincidir, o que pode significar que ele está enfrentando tempo de inatividade ou algo semelhante. Por exemplo, se olharmos para as duas últimas linhas, isso significa que meu servidor saiu de 2 de abril às 09:17 até 03 de abril às 02:31?

Quanto às informações básicas, este é um servidor Debian Squeeze.

EDITAR

Se as últimas colunas são hora de início, hora de parada e tempo de atividade, como você pode interpretar essas duas linhas:

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)   

A segunda sessão parece terminar após o início da primeira, o que não faz sentido para mim.

Acho que este é um post de três anos, mas responderei de qualquer maneira, para o benefício de qualquer pessoa que o encontre no futuro, como fiz recentemente.

Ao ler outras postagens e monitorar a saída por um período, parece que cada linha lista a data e hora de início da sessão, o horário de término da sessão (mas não a data de término) e a duração da sessão. (por quanto tempo eles estiveram conectados) em um formato como

(dias + horas: minutos)

O usuário de reinicialização parece ter sido registrado como logon sempre que o sistema é iniciado e desligado quando o sistema foi reiniciado ou desligado e, nessas linhas, as informações de "duração da sessão" são o período de tempo (dias + horas: minutos) essa "sessão" durou, ou seja, quanto tempo o sistema ficou ativo antes de ser desligado.

Para mim, a entrada de reinicialização mais recente mostra a hora atual como a hora de "desconectado" e os dados de duração da sessão para essa entrada correspondem à saída de tempo de atividade atual.

Então nesta linha:

reinicie a inicialização do sistema 3.2.13-grsec-xxx terça-feira, 3 de abril, 07:34 - 09:17 (9 + 01: 42)

O sistema foi iniciado na terça-feira, 3 de abril, às 7:34, e foi encerrado 9 dias e 1 hora e 42 minutos depois (em 12 de abril), às 9:17 da manhã. (Ou, essa saída foi coletada naquele momento, e esta é a entrada de reinicialização mais recente, e "reboot" ainda não "desconectou". Nesse caso, a saída será alterada se você executar o último comando novamente.)

Por que você teria duas entradas para o usuário de reinicialização, em 3 de abril, que duraram 9 dias, é um mistério para mim; meus sistemas não fazem isso.

Sumário

• O primeiro registro de data e hora parece ser o horário em que o sistema ficou inativo durante a reinicialização.
• O segundo registro de data e hora e o tempo decorrido não são muito úteis.
• Passar a -xopção para lastpode ser útil para mostrar outros eventos relacionados a desligamentos e alterações no nível de execução que influenciam os carimbos de data e hora mostrados nas rebootlinhas. A tuptimeferramenta mencionada em outra resposta pode deixar isso mais claro, mas eu não olhei para ela.

Detalhes

A lastpágina de manual no CentOS 6 e 7 diz:

A reinicialização do pseudo usuário faz logon sempre que o sistema é reiniciado.

Ele não diz nada sobre quando o usuário efetua logout, e as evidências mostradas abaixo parecem sugerir que nenhum tempo de logout é explicitamente registrado. As páginas de manual reboote shutdowntêm mais detalhes sobre o registro das alterações no nível de execução, se alguém estiver interessado.

Nos testes, parece que o tempo de logon está atrasado no processo de desligamento - não é a partir do momento em que o rebootcomando foi emitido.

Portanto, parece que os horários de logout (o segundo registro de data e hora) e a duração em que a "reinicialização" foi registrada (mostrada entre parênteses) provavelmente devem ser ignorados.

Se você passar a -Fopção para last, ele mostrará carimbos de data e hora completos, o que torna um pouco mais claro que a máquina não está sendo reinicializada por coincidência ao mesmo tempo, apenas mostrando o mesmo carimbo de data e hora algumas vezes. Além disso, se você passar o -xsinalizador, ele mostra "entradas de desligamento do sistema e executa alterações de nível".

Aqui, eu o executei no CentOS 7 e também passei a -Ropção de suprimir a coluna nome do host / versão do kernel. Também removi alguns logins raiz desinteressantes:

# 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)

As 6 linhas de "reinicialização" acima de tudo têm um tempo de logoff igual ao horário atual.

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)

As 5 linhas de "reinicialização" acima de tudo têm um tempo de logoff igual ao tempo do "sistema de desligamento" que as seguiu.

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)

O tempo de logoff de "reinicialização" corresponde ao tempo de "desligamento do sistema" novamente.

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 acima.

Suponho pelos resultados acima que nenhum tempo explícito de logout é registrado para o pseudo usuário "reboot", portanto, lastatribui a ele um tempo de logout da próxima "inicialização do sistema de desligamento" ou o horário atual se não houver uma "inicialização do sistema de desligamento "seguindo.

As entradas "runlevel (to lvl 3)" parecem ter um tempo de logout mais sensato, mas não parecem levar em consideração as falhas.

Na página de manual, as últimas colunas parecem ser o início da sessão, os horários de parada e a duração da sessão.

Eu estava olhando quando um servidor foi reinicializado pelo provedor (uma tarefa agendada para corrigir as vulnerabilidades recentes da CPU do Meltdown e Spectre) e qual foi o tempo de inatividade real da operação.

Eu uso uma alternativa para a "última reinicialização", porque sinto que é muito claro, como você já notou.

Executando tuptime -l, posso ver a seguinte lista do comportamento do 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

No qual está claro que o shudown foi realizado após o procedimento de desligamento do sistema na hora e data específicas "02:56:47 AM 18/01/2018". O tempo de inatividade foi de "18 minutos e 44 segundos" e a inicialização ocorreu em "03:15:31 - 18/01/2018" e ainda está em execução no momento.

O último tempo de atividade da linha, como você diz. As duas últimas colunas reiniciam a hora e a hora atual, eu acho. Porque quando executo o último comando, a segunda coluna de trás mostra a hora atual e sempre muda.