Significati delle colonne nel comando "ultimo"

Mentre stavo investigando su un server che si riavvia in modo regolare, ho iniziato a cercare l'utilità "ultima" ma il problema è che non riesco a trovare esattamente cosa significano le colonne. Ovviamente ho guardato attraverso l'uomo ma non contiene queste informazioni.

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)   

Le prime colonne hanno senso fino alle versioni del kernel incluse. Cosa rappresentano esattamente questi tempi? L'ultimo sembra essere il tempo di attività.

In secondo luogo, si suppone che questo sia un server 24 ore su 24, 7 giorni su 7, tranne per il fatto che i tempi non sembrano coincidere, il che potrebbe significare che si verificano tempi di inattività o qualcosa di simile. Ad esempio, se guardiamo le ultime due righe, significa che il mio server è stato spento dal 2 aprile alle 09:17 fino al 3 aprile 02:31?

Per quanto riguarda le informazioni di base, si tratta di un server Debian Squeeze.

MODIFICARE

Se le ultime colonne sono ora di inizio, ora di fine e tempo di attività, come puoi interpretare queste due righe:

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 seconda sessione sembra terminare dopo l'inizio della prima, il che non ha senso per me.

Immagino che questo sia un post di tre anni, ma risponderò comunque, a beneficio di chiunque altro lo incontrerà in futuro, come ho appena fatto di recente.

Dalla lettura di altri post e dal monitoraggio dell'output da me stesso per un periodo di tempo, sembra che ogni riga elenchi la data e l'ora di inizio della sessione, l'ora di fine della sessione (ma non la data di fine) e la durata della sessione (per quanto tempo sono stati registrati) in un formato simile

(giorni + ore: minuti)

Sembra che l'utente al riavvio abbia notato di aver effettuato l'accesso ogni volta che il sistema è stato avviato e spento quando il sistema è stato riavviato o arrestato e su quelle righe, le informazioni sulla "durata della sessione" sono la durata (giorni + ore: minuti) quella "sessione" è durata, vale a dire per quanto tempo è rimasto attivo il sistema prima che fosse spento.

Per me, la voce di riavvio più recente mostra l'ora corrente come l'ora di "disconnessione" e i dati sulla durata della sessione per quella voce corrispondono all'output di uptime corrente.

Quindi su questa linea:

riavviare l'avvio del sistema 3.2.13-grsec-xxx mar 3 aprile 07:34 - 09:17 (9 + 01: 42)

Il sistema è stato avviato martedì 3 aprile, alle 7:34, e si è spento 9 giorni e 1 ora e 42 minuti dopo (il 12 aprile), alle 9:17 del mattino. (Oppure, questo output è stato raccolto in quel momento, e questa è la voce di riavvio più recente, e "reboot" non si è ancora effettivamente "disconnesso". Nel qual caso l'output cambierà se si esegue di nuovo l'ultimo comando.)

Perché dovresti avere 2 voci per l'utente di riavvio, il 3 aprile, lunghe entrambe 9 giorni, è un mistero per me; i miei sistemi non lo fanno.

Sommario

• Il primo timestamp sembra essere il momento in cui il sistema si è spento durante il riavvio.
• Il secondo timestamp e il tempo trascorso non sono molto utili.
• Passare l' -xopzione a lastpuò essere utile per mostrare altri eventi relativi a arresti ed eseguire cambi di livello che influenzano i timestamp mostrati nelle rebootlinee. Lo tuptimestrumento come indicato in un'altra risposta può renderlo più chiaro, ma non l'ho visto.

Dettagli

La lastpagina man su CentOS 6 e 7 dice:

Il riavvio dell'utente pseudo accede ogni volta che si riavvia il sistema.

Non dice nulla su quando l'utente si disconnette e le prove mostrate di seguito sembrano suggerire che nessun tempo di disconnessione viene registrato in modo esplicito. Le pagine man reboote shutdownhanno maggiori dettagli sulla registrazione delle variazioni del livello di esecuzione se qualcuno è interessato.

Dal test, sembra che il tempo di accesso sia in ritardo nel processo di chiusura - non è dal momento in cui il rebootcomando è stato emesso.

Pertanto sembrerebbe che i tempi di disconnessione (il secondo timestamp) e la durata per la quale è stato effettuato il login "riavvio" (mostrato tra parentesi), dovrebbero essere probabilmente ignorati.

Se passi l' -Fopzione a last, ti mostrerà i timestamp completi, il che rende leggermente più chiaro che la macchina non viene riavviata casualmente allo stesso tempo, mostra solo lo stesso identico timestamp alcune volte. Inoltre, se si passa il -xflag, viene visualizzato "voci di arresto del sistema ed esecuzione modifiche di livello".

Qui, l'ho eseguito su CentOS 7 e ho anche passato l' -Ropzione per sopprimere la colonna versione hostname / kernel. Ho anche eliminato alcuni login root poco interessanti:

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

Le 6 righe di "riavvio" hanno soprattutto un tempo di disconnessione uguale all'ora corrente.

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)

Le 5 righe di "riavvio" hanno soprattutto un tempo di disconnessione pari al tempo del "sistema di spegnimento" che li ha seguiti.

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)

Il tempo di disconnessione "riavvio" corrisponde nuovamente al tempo di "spegnimento 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)

Come sopra.

Presumo dai risultati precedenti che non viene registrato alcun tempo di disconnessione esplicito per l'utente "riavvio" dello pseudo, quindi gli lastassegna un tempo di disconnessione del successivo "avvio del sistema di spegnimento" o l'ora corrente se non esiste un "avvio del sistema di spegnimento "seguendolo.

Le voci "runlevel (to lvl 3)" sembrano avere un tempo di logout più ragionevole indovinato per loro, ma non sembra tener conto degli arresti anomali.

Dalla manpage, le ultime colonne sembrano essere l'inizio della sessione, i tempi di arresto e la durata della sessione.

Stavo osservando quando un server è stato riavviato dal provider del server (un'attività pianificata per correggere le recenti vulnerabilità della CPU Meltdown e Spectre) e quali sono stati i reali tempi di inattività dell'operazione.

Uso un'alternativa all '"ultimo riavvio" perché ritengo che sia evidente come si nota già.

In esecuzione tuptime -lposso vedere il seguente elenco del comportamento 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

In cui è chiaro che lo shudown è stato eseguito seguendo la procedura di spegnimento del sistema all'ora e alla data specifiche "02:56:47 AM 18/01/2018". Il tempo di inattività è stato lungo "18 minuti e 44 secondi" e l'avvio è stato alle "03:15:31 AM 18/01/2018" ed è ancora in corso per ora.

L'ultimo tempo di attività come dici tu. Credo che il tempo di riavvio delle ultime due colonne e l'ora corrente. Perché quando eseguo l'ultimo comando la seconda colonna dal retro mostra l'ora corrente e cambia sempre.