Significati delle colonne nell'ultimo comando

Immagino che questo sia un post vecchio di tre anni, ma risponderò comunque, a beneficio di chiunque altro si imbatta in esso in futuro, come ho appena fatto di recente.

Dalla lettura di altri post e dal monitoraggio personale dell'output 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 connessi) in un formato come

(giorni+ore:minuti)

L'utente di riavvio sembra essere annotato come aver effettuato l'accesso ogni volta che il sistema viene avviato e disattivato quando il sistema è stato riavviato o spento, e su quelle righe, le informazioni sulla "durata della sessione" sono il periodo di tempo (giorni + ore:minuti) quella "sessione" è durata, ovvero per quanto tempo il sistema è rimasto attivo prima di essere spento.

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

Quindi su questa riga:

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 ed è stato 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 è ancora "disconnesso". In tal caso, l'output cambierà se si esegue nuovamente l'ultimo comando.)

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

Riepilogo

• Il primo timestamp sembra essere l'ora in cui il sistema si è bloccato durante il riavvio.
• Il secondo timestamp e il tempo trascorso non sono molto utili.
• Passare lo -x opzione a last può essere utile per mostrare altri eventi relativi a arresti e modifiche al livello di esecuzione che influenzano i timestamp mostrati nel reboot linee. Il tuptime lo strumento come indicato in un'altra risposta potrebbe renderlo più chiaro, ma non l'ho esaminato.

Dettagli

Il last pagina man su CentOS 6 e 7 dice:

Lo pseudo riavvio dell'utente accede ogni volta che il sistema viene riavviato.

Non dice nulla su quando l'utente si disconnette e le prove mostrate di seguito sembrano suggerire che nessun tempo di disconnessione sia esplicitamente registrato. Il reboot e shutdown le pagine man contengono maggiori dettagli sulla registrazione delle modifiche al livello di esecuzione se qualcuno è interessato.

Dai test, sembra che l'ora di accesso sia in ritardo nel processo di chiusura - non è dall'ora in cui il reboot comando è stato emesso.

Pertanto sembrerebbe che i tempi di disconnessione (il secondo timestamp) e la durata per cui è stato effettuato l'accesso al "riavvio" (mostrato tra parentesi), debbano probabilmente essere ignorati.

Se superi il -F opzione a last , ti mostrerà i timestamp completi, il che rende leggermente più chiaro che la macchina non viene riavviata per coincidenza nello stesso momento, mostra solo lo stesso timestamp alcune volte. Inoltre, se superi il -x flag, mostra "voci di arresto del sistema e modifiche al livello di esecuzione".

Ecco, l'ho eseguito su CentOS 7 e ho anche passato il -R opzione per sopprimere la colonna nome host/versione kernel. Ho anche rimosso alcuni accessi 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 "reboot" soprattutto hanno un tempo di logout pari 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 "reboot" soprattutto hanno un tempo di logout pari al tempo dello "shutdown system down" che le ha seguite.

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 logout "reboot" corrisponde nuovamente al tempo di "shutdown system down".

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 venga registrato alcun tempo di disconnessione esplicito per lo pseudo utente "reboot", quindi last gli assegna un'ora di logout del prossimo "avvio del sistema di spegnimento", o l'ora corrente se non è seguito da un "avvio del sistema di spegnimento".

Le voci "runlevel (to lvl 3)" sembrano avere un tempo di logout più sensato, ma non sembra tenere conto dei crash.