Significados das colunas no comando “last”

Question

Enquanto investigava um servidor que está reinicializando de forma regular, comecei a pesquisar o utilitário "last", mas o problema é que não consigo encontrar o que as colunas significam exatamente. Eu, claro, olhei através do homem, mas ele não contém essa informação.

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, este é suposto ser um servidor em 24/7, exceto os horários não parecem corresponder, o que poderia significar que está ocorrendo inatividade ou algo parecido. Por exemplo, se olharmos para as duas últimas linhas, isso significa que o meu servidor estava desligado de 2 de abril de 09:17 até 03 de abril de 02:31?

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

EDITAR

Se as últimas colunas forem 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 depois que a primeira começa, o que não faz sentido para mim.

    

Answer 1

Acho que essa é uma postagem de três anos, mas responderei de qualquer maneira, para o benefício de qualquer outra pessoa que aconteça no futuro, como fiz recentemente.

A partir da leitura de outras postagens e do acompanhamento da saída por um período de tempo, parece que cada linha lista a data e hora de início da sessão, a hora final da sessão (mas não a data final) e a duração da sessão (quanto tempo eles estavam logados) em um formato como

(dias + horas: minutos)

O usuário da reinicialização parece ter entrado em contato sempre que o sistema foi iniciado e desligado quando o sistema foi reinicializado ou encerrado, e nessas linhas, a informação de "duração da sessão" é o período de tempo (dias + horas) : minutos) que a "sessão" durou, ou seja, quanto tempo o sistema estava ativo antes de ser encerrado.

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

Então, nesta linha:

reinicialização do sistema boot 3.2.13-grsec-xxx Ter Abr 3 07:34 - 09:17 (9 + 01: 42)

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

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

    

Answer 2

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

    

Answer 3

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

Eu uso uma alternativa para "última reinicialização" porque eu sinto que é muito claro como você já percebeu também.

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

Em que fica claro que o shudown foi feito seguindo o procedimento de desligamento do sistema na hora e data específicas "02:56:47 AM 01/18/2018". O tempo de inatividade foi ao longo de "18 minutos e 44 segundos" e a inicialização foi no "03:15:31 AM 01/18/2018" e ainda está funcionando por enquanto.

    

Answer 4

Resumo

• 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.
• A passagem da opção -x para last pode ser útil para mostrar outros eventos relacionados a desligamentos e alterações no nível de execução que influenciam os registros de data e hora mostrados nas linhas reboot . A ferramenta tuptime , conforme referenciada em outra resposta, pode deixar isso mais claro, mas eu não olhei para ela.

Detalhes

A página last man no CentOS 6 e 7 diz:

The pseudo user reboot logs in each time the system is rebooted.

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 reboot e shutdown man têm mais detalhes sobre como registrar as alterações no nível de execução se alguém estiver interessado.

A partir do teste, parece que o tempo de login está atrasado no processo de desligamento - não é a partir do momento em que o comando reboot foi emitido.

Portanto, parece que os tempos de logoff (o segundo registro de data e hora) e a duração da entrada "reinicialização" (mostrada entre parênteses) provavelmente devem ser ignorados.

Se você passar a opção -F para last , ela mostrará os timestamps completos, o que torna um pouco mais claro que a máquina não está sendo reinicializada coincidentemente ao mesmo tempo, mostrando apenas o mesmo timestamp poucas vezes. Além disso, se você passar o sinal -x , ele mostrará "entradas de desligamento do sistema e alterações no nível de execução".

Aqui, executei-o no CentOS 7 e também passei a opção -R para suprimir a coluna hostname / kernel version. Eu também retirei alguns logins de 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 logout 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 logout igual ao tempo do "desligamento do sistema" 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 logout "reinicialização" corresponde ao "desligamento do sistema inativo" 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.

Eu presumo dos resultados acima que nenhum tempo de logout explícito é registrado para o pseudo-usuário "reboot", então last atribui a ele um tempo de logout do próximo "shutdown system boot" ou a hora atual se não houver t uma "inicialização do sistema de desligamento" seguindo-a.

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

    

Answer 5

O último tempo de atividade da linha, como você diz. Última hora de reinicialização de duas colunas e hora atual eu acho. Porque quando eu executo o último comando, a segunda coluna mostra a hora atual e sempre muda.