Je suppose qu'il s'agit d'un message vieux de trois ans, mais je répondrai quand même, pour le bénéfice de tous ceux qui le croiseront à l'avenir, comme je viens de le faire récemment.
En lisant d'autres messages et en surveillant moi-même la sortie 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 s'étant connecté 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 de "durée de session" sont la durée (jours + heures:minutes) cette "session" a duré, c'est-à-dire combien de temps le système était actif avant d'être arrêté.
Pour moi, l'entrée de redémarrage la plus récente affiche 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 1h42 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" ne s'est pas encore "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 duraient toutes les deux 9 jours, est un mystère pour moi ; mes systèmes ne font pas ça.
Résumé
- Le premier horodatage semble être l'heure à laquelle le système s'est arrêté lors du redémarrage.
- Le deuxième horodatage et le temps écoulé ne sont pas très utiles.
- Passer le
-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 dans lerebootlignes. Letuptimel'outil référencé dans une autre réponse peut rendre cela plus clair, mais je ne l'ai pas regardé.
Détails
Le last La page de manuel sur CentOS 6 et 7 indique :
Le redémarrage du pseudo-utilisateur se connecte à chaque redémarrage du système.
Il ne dit rien sur le moment où l'utilisateur se déconnecte, et les preuves présentées ci-dessous semblent suggérer qu'aucune heure de déconnexion n'est explicitement enregistrée. Le reboot et shutdown les pages de manuel contiennent plus de détails sur l'enregistrement des changements de niveau d'exécution si quelqu'un est intéressé.
D'après les tests, il semble que l'heure de connexion remonte à la fin du processus d'arrêt - ce n'est pas à partir du moment où le reboot la commande 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ée entre parenthèses) devraient probablement être ignorées.
Si vous passez le -F option à last , il vous montrera des horodatages complets, ce qui indique un peu plus clairement que la machine n'est pas redémarrée par coïncidence en même temps, elle affiche simplement le même horodatage plusieurs fois. Aussi, si vous passez le -x flag, 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é le -R option pour supprimer la colonne nom d'hôte/version du 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 "reboot" ont surtout une heure de déconnexion égale à l'heure courante.
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 "reboot" ont avant tout un temps de déconnexion égal au temps du "shutdown system down" qui les a suivis.
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)
l'heure de déconnexion "reboot" correspond à nouveau à l'heure "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)
Comme ci-dessus.
Je suppose d'après les résultats ci-dessus qu'aucune heure de déconnexion explicite n'est enregistrée pour le "redémarrage" du pseudo utilisateur, donc last lui attribue 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" qui le suit.
Les entrées "runlevel (to lvl 3)" semblent avoir un temps de déconnexion plus raisonnable, mais cela ne semble pas prendre en compte les plantages.