Signification des colonnes dans la commande "last"

Comme j'étudiais un serveur qui redémarre de façon régulière, j'ai commencé à chercher dans le "dernier" utilitaire mais le problème est que je ne peux pas trouver exactement ce que les colonnes signifient. J'ai bien sûr regardé l'homme mais il ne contient pas ces informations.

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)   

Les premières colonnes ont du sens pour les versions du noyau incluses. Que représentent exactement ces temps? Le dernier semble être la disponibilité.

Deuxièmement, il est censé être un serveur 24h / 24 et 7j / 7, sauf que les heures ne semblent pas correspondre, ce qui pourrait signifier qu'il connaît des temps d'arrêt ou quelque chose de similaire. Par exemple, si nous regardons les deux dernières lignes, cela signifie-t-il que mon serveur était éteint du 2 avril 09:17 au 3 avril 02:31?

Quant aux informations générales, il s'agit d'un serveur Debian Squeeze.

ÉDITER

Si les dernières colonnes sont l'heure de début, l'heure d'arrêt et la disponibilité, comment pouvez-vous interpréter ces deux lignes:

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 deuxième session semble se terminer après le début de la première, ce qui n'a pas de sens pour moi.

Je suppose que c'est un article de trois ans, mais je répondrai quand même, pour le bénéfice de toute autre personne qui se produira à l'avenir, comme je viens de le faire récemment.

De la lecture d'autres publications et de la surveillance de la sortie moi-même sur une période de temps, il semble que chaque ligne répertorie la date et l'heure de début de la session, l'heure de fin de la session (mais pas la date de fin) et la durée de la session (combien de temps ils ont été connectés) dans un format comme

(jours + heures: minutes)

L'utilisateur de redémarrage semble être noté comme ayant ouvert une session chaque fois que le système est démarré, et éteint lorsque le système a été redémarré ou arrêté, et sur ces lignes, les informations sur la "durée de la session" sont la durée (jours + heures: minutes) cette "session" a duré, c'est-à-dire combien de temps le système était en place avant son arrêt.

Pour moi, l'entrée de redémarrage la plus récente indique l'heure actuelle comme l'heure de «déconnexion» et les données de durée de session pour cette entrée correspondent à la sortie de disponibilité actuelle.

Donc sur cette ligne:

redémarrer le démarrage du système 3.2.13-grsec-xxx mar 3 avril 07:34 - 09:17 (9 + 01: 42)

Le système a été démarré le mardi 3 avril à 7h34 et il a été arrêté 9 jours et 1 heure et 42 minutes plus tard (le 12 avril), à 9h17 du matin. (Ou, cette sortie a été collectée à ce moment-là, et il s'agit de l'entrée de redémarrage la plus récente, et "reboot" n'a pas encore été "déconnecté". Dans ce cas, la sortie changera si vous exécutez à nouveau la dernière commande.)

Pourquoi vous auriez 2 entrées pour l'utilisateur de redémarrage, le 3 avril, qui étaient toutes les deux de 9 jours, est un mystère pour moi; mes systèmes ne font pas ça.

Sommaire

• Le premier horodatage semble être l'heure à laquelle le système s'est arrêté pendant le redémarrage.
• Le deuxième horodatage et le temps écoulé ne sont pas très utiles.
• Le passage de l' -xoption à lastpeut être utile pour afficher d'autres événements liés aux arrêts et aux changements de niveau d'exécution qui influencent les horodatages affichés sur les rebootlignes. L' tuptimeoutil référencé dans une autre réponse peut rendre cela plus clair, mais je ne l'ai pas examiné.

Détails

La lastpage de manuel sur CentOS 6 et 7 indique:

Le pseudo utilisateur reboot se connecte à chaque redémarrage du système.

Il ne dit rien sur le moment où l'utilisateur se déconnecte, et les preuves ci-dessous semblent suggérer qu'aucun temps de déconnexion n'est explicitement enregistré. Les pages de manuel rebootet shutdowncontiennent plus de détails sur l'enregistrement des modifications de niveau d'exécution si quelqu'un est intéressé.

D'après les tests, il semble que l'heure de connexion est en retard dans le processus de fermeture - ce n'est pas à partir du moment où la rebootcommande a été émise.

Par conséquent, il semblerait que les heures de déconnexion (le deuxième horodatage) et la durée pendant laquelle le "redémarrage" a été connecté (indiqué entre parenthèses) devraient probablement être ignorées.

Si vous passez l' -Foption à last, cela vous montrera les horodatages complets, ce qui rend légèrement plus clair que la machine n'est pas redémarrée par coïncidence en même temps, elle montre simplement le même horodatage à quelques reprises. En outre, si vous passez l' -xindicateur, il affiche «les entrées d'arrêt du système et les changements de niveau d'exécution».

Ici, je l'ai exécuté sur CentOS 7, et j'ai également passé l' -Roption pour supprimer la colonne de version du nom d'hôte / noyau. J'ai également supprimé certaines connexions root inintéressantes:

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

Les 6 lignes de "redémarrage" ont surtout un temps de déconnexion égal à l'heure actuelle.

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)

Les 5 lignes de "redémarrage" ont surtout un temps de déconnexion égal au temps de "l'arrêt du système" qui les a suivies.

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)

Le temps de déconnexion du «redémarrage» correspond à nouveau au temps d'arrêt du système.

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)

Comme ci-dessus.

Je suppose à partir des résultats ci-dessus qu'aucune heure de déconnexion explicite n'est enregistrée pour le pseudo utilisateur "reboot", lastlui attribue donc une heure de déconnexion du prochain "démarrage du système d'arrêt", ou l'heure actuelle s'il n'y a pas de "démarrage du système d'arrêt" "le suivre.

Les entrées "runlevel (to lvl 3)" semblent avoir un temps de déconnexion plus sensible deviné pour elles, mais il ne semble pas prendre en compte les plantages.

D'après la page de manuel, les dernières colonnes semblent être le début de la session, les heures d'arrêt et la durée de la session.

Je cherchais quand un serveur a été redémarré par le fournisseur de serveur (une tâche planifiée pour corriger les vulnérabilités récentes du processeur Meltdown et Spectre) et quel était le véritable temps d'arrêt de l'opération.

J'utilise une alternative au "dernier redémarrage" parce que je pense que cela manque de clarté comme vous le remarquez déjà.

En exécutant, tuptime -lje peux voir la liste suivante du comportement du système:

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

Dans lequel est clair que l'arrêt a été effectué après la procédure d'arrêt du système à l'heure et à la date spécifiques "02:56:47 AM 18/01/2018". Le temps d'arrêt a duré "18 minutes et 44 secondes" et le démarrage était à "03:15:31 AM 18/01/2018" et il fonctionne toujours pour l'instant.

La dernière ligne de disponibilité comme vous le dites. Le temps de redémarrage des deux dernières colonnes et l'heure actuelle, je pense. Parce que lorsque j'exécute la dernière commande, la deuxième colonne de l'arrière montre l'heure actuelle et change toujours.