J’ai éteint le serveur pendant une période puis, je l’ai rallumé, j’aimerai savoir s’il y a un moyen pour calculer la période d’inaccessibilité du serveur?
Je me suis dit que je pouvais calculer la date du dernier shutdown et celle du dernier reboot en exécutant les commandes ci-dessous: dernier reboot:
who -b dernier shutdown:
last -x|grep shutdown | head -1
mais la première n’a rien donné mais je viens de me rendre compte en écrivant ce message que cette commande affiche la date du dernier reboot et non du dernier start (si je peux dire Ça) car je ne redémarre jamais le serveur, soit je l’éteint ou je l’allume, peut être c’était Ça le problème.
Avez-vous une autre idée pour calculer la période d’incessibilité d’un serveur ?
fp2@debpacha:~ $ last -x reboot | head
reboot system boot 4.19.0-12-amd64 Fri Nov 6 15:18 still running
reboot system boot 4.19.0-10-amd64 Mon Aug 24 21:51 still running
reboot system boot 4.19.0-9-amd64 Wed Aug 5 16:46 still running
reboot system boot 4.19.0-9-amd64 Tue Jul 21 12:10 still running
reboot system boot 4.19.0-9-amd64 Mon Jul 20 23:13 - 01:51 (02:37)
reboot system boot 4.19.0-9-amd64 Mon Jul 20 22:57 - 23:06 (00:09)
reboot system boot 4.19.0-9-amd64 Wed Jul 1 08:19 - 23:06 (19+14:47)
reboot system boot 4.19.0-9-amd64 Tue Jun 23 07:41 - 23:06 (27+15:25)
reboot system boot 4.19.0-9-amd64 Mon Jun 15 13:33 - 23:06 (35+09:33)
reboot system boot 4.19.0-9-amd64 Sun Jun 14 11:17 - 01:48 (14:30)
fp2@debpacha:~ $
Pas terrible comme résultat
Ceci sur un système Debian avec une batterie quasiment HS. J’utilise les consoles 2 et 3 + bureau XFCE sur tty7.
l’utilisation de l’option Storage=persistent génère une erreur lors du démontage du systeme de fichier en cas de reboot ou d’arrêt de la machine. Il faut obligatoirement utiliser la version systemd > 241 ou 243 (je ne suis plus sur pour le numéro de version).
De fait, la version backports de systemd est alors nécessaire.
Tu as un signalement de bogue pour cela ?
Je n’ai jamais observé ce comportement, ni sous Debian stretch, ni sous buster (systemd 241-7~deb10u4). Par contre j’ai toujours eu Storage=auto avec un dossier /var/log/journal
Ca te donne exactement ce que tu recherches je crois
"
shutdown system down Sat Dec 5 20:00:08 2020 - Sun Dec 6 05:22:48 2020 (09:22) 0.0.0.0 shutdown system down Fri Dec 4 19:07:44 2020 - Sat Dec 5 05:44:44 2020 (10:37) 0.0.0.0 shutdown system down Thu Dec 3 19:10:58 2020 - Fri Dec 4 05:08:10 2020 (09:57) 0.0.0.0 shutdown system down Thu Dec 3 10:45:01 2020 - Thu Dec 3 10:45:48 2020 (00:00) 0.0.0.0 shutdown system down Wed Dec 2 18:29:09 2020 - Thu Dec 3 06:14:03 2020 (11:44) 0.0.0.0 shutdown system down Wed Dec 2 09:01:05 2020 - Wed Dec 2 11:05:38 2020 (02:04) 0.0.0.0 shutdown system down Wed Dec 2 07:38:39 2020 - Wed Dec 2 07:44:07 2020 (00:05) 0.0.0.0 shutdown system down Wed Dec 2 07:28:33 2020 - Wed Dec 2 07:33:36 2020 (00:05) 0.0.0.0 shutdown system down Wed Dec 2 07:22:16 2020 - Wed Dec 2 07:22:54 2020 (00:00) 0.0.0.0 shutdown system down Tue Dec 1 20:30:59 2020 - Wed Dec 2 04:42:51 2020 (08:11) 0.0.0.0 shutdown system down Tue Dec 1 12:35:56 2020 - Tue Dec 1 12:36:17 2020 (00:00) 0.0.0.0 shutdown system down Tue Dec 1 04:21:12 2020 - Tue Dec 1 07:57:45 2020 (03:36) 0.0.0.0
Bof bof
Cela me donne le dernier arrêt du 21 juillet. Alors que depuis cette date j’ai fait des redémarrages (reboot) les 5 et 24 août et le 6 novembre.
fp2@debpacha:~ 1 $ last -iadwxdF | fgrep boot | head -7
reboot system boot Fri Nov 6 15:18:32 2020 still running 0.0.0.0
reboot system boot Mon Aug 24 21:51:22 2020 still running 0.0.0.0
reboot system boot Wed Aug 5 16:46:45 2020 still running 0.0.0.0
reboot system boot Tue Jul 21 12:10:47 2020 still running 0.0.0.0
reboot system boot Mon Jul 20 23:13:19 2020 - Tue Jul 21 01:51:11 2020 (02:37) 0.0.0.0
reboot system boot Mon Jul 20 22:57:52 2020 - Mon Jul 20 23:06:57 2020 (00:09) 0.0.0.0
reboot system boot Wed Jul 1 08:19:36 2020 - Mon Jul 20 23:06:57 2020 (19+14:47) 0.0.0.0
fp2@debpacha:~ $
Il me semble que la commande last (d’origine BSD si je ne m’abuse) était valable dans les temps bénis où il n’y avait pas la possibilité de combiner deux types de gestionnaires de connexions + logind de systemd : lightdm et tmux (lancé dans une console) et un système de veille profonde (hibernation).
Quand je démarre, je ne rentre pas mes identifiants dans la fenêtre graphique lightdm, mais je bascule sur tty2 et je me connecte en mode console. En effet j’ai installé keychain et je ne veux taper ma phrase de passe sshqu’une fois et tranquillement sans être importuné par un éventuel dialogue graphique peu lisible (qui m’obligerait à zoomer).
Je profite aussi du shell sur la console tty2 pour consulter l’état de la batterie, via des commandes personnalisées.
Il se trouve en plus que j’aime bien avoir aussi une session tmux sur une console tty3. Je me connecte en graphique et j’ouvre souvent une autre session tmux dans un terminal.
Tout ceci combiné avec des séquences quotidiennes d’hibernation nous amène à une commande last qui a loupé le coche.
Il faudrait écrire un rapport de bogue : la commande last a un train de retard. Cela ferait un bug de plus pour util-linux mais décrire tout cela en anglais ne m’enchante pas. Je ne sais pas si le jeu en vaut la chandelle.
Cordialement,
Regards,
Mit freundlichen Grüßen,
مع تحياتي الخالصة
F. Petitjean
Ingénieur civil du Génie Maritime.
« On ne perd pas son temps en aiguisant ses outils. »
Proverbe français
« Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » (R. Devos)
« J’ai éteint le serveur pendant une période puis, je l’ai rallumé, j’aimerai savoir s’il y a un moyen pour calculer la période d’inaccessibilité du serveur? »
C’etait ce qui était demandé - Il n’était à aucun moment fait état d’un reboot mais peut etre ne sais je pas lire
Si tu cherche à calculer à propos de l’uptime, du monitoring simple sur le ping suffit à mon avis.
Si il est up il répond, sinon non, à après à toi de travailler avec une api ou un outil permettant de calculer le temps up et down.
fp2@debpacha:~ $ last -iadwxdF | fgrep shutdown | head -5
shutdown system down Tue Jul 21 01:51:11 2020 - Tue Jul 21 12:10:47 2020 (10:19) 0.0.0.0
shutdown system down Mon Jul 20 23:06:57 2020 - Mon Jul 20 23:13:19 2020 (00:06) 0.0.0.0
shutdown system down Mon Jun 15 01:48:14 2020 - Mon Jun 15 13:33:43 2020 (11:45) 0.0.0.0
shutdown system down Sat Jun 13 14:36:52 2020 - Sun Jun 14 11:17:26 2020 (20:40) 0.0.0.0
shutdown system down Sat Jun 13 02:35:01 2020 - Sat Jun 13 12:56:03 2020 (10:21) 0.0.0.0
fp2@debpacha:~ $
et d’ailleurs j’avis écrit
Je suis allé un peu vite dans ma recherche de cette anomalie dans la sortie d’une commande last, je suis désolé mais actuellement se fier à last pour ce genre de choses ne me semble pas pertinent.
Je pense qu’avec un vrai arrêt il n’y a pas de problème mais avouez que rater 3 redémarrages c’est un peu gros.
La réponse de Clochette me paraît judicieuse.
Cordialement,
Regards,
Mit freundlichen Grüßen,
مع تحياتي الخالصة
F. Petitjean
Ingénieur civil du Génie Maritime.
« Il semble que la perfection soit atteinte, non quand il n’y a
plus rien à ajouter mais quand il n’y a plus rien à retrancher »
Saint-Exupéry -Terre des hommes , chapitre III , L’avion.
