# Connaitre la période d'inaccessibilité d'un serveur **URL:** \ **Category:** Support Debian\ **Created:** [Décembre 5, 2020, 10:27 UTC](https://www.debian-fr.org/t/connaitre-la-periode-dinaccessibilite-dun-serveur/83472 "2020-12-05T10:27:08Z")\ **Posts on this page:** 12\ **Page:** 1
**Author:** ![pipa85](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/p/7ea924/32.png) [@pipa85](https://www.debian-fr.org/u/pipa85)\ **Post date:** [Décembre 5, 2020, 10:27 UTC](https://www.debian-fr.org/t/connaitre-la-periode-dinaccessibilite-dun-serveur/83472/1 "2020-12-05T10:27:08Z")
Bonjour, 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 ? Je vous remercie par avance pour votre aide. ---
**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\ **Post date:** [Décembre 5, 2020, 1:27 UTC](https://www.debian-fr.org/t/connaitre-la-periode-dinaccessibilite-dun-serveur/83472/2 "2020-12-05T13:27:07Z")
regarde le fichier /var/log/syslog. Le démarrage et l’arrêt d’y trouveront. ---
**Author:** ![anon70622873](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/278dde/32.png) [@anon70622873](https://www.debian-fr.org/u/anon70622873)\ **Post date:** [Décembre 5, 2020, 1:44 UTC](https://www.debian-fr.org/t/connaitre-la-periode-dinaccessibilite-dun-serveur/83472/3 "2020-12-05T13:44:52Z")
```auto who -b ``` devrait fonctionner. Cela affiche la date du dernier démarrage, peut importe que _shutdown_ ou _reboot_ ait été utilisé au préalable. Pour voir les dernières dates d’extinction : ```nohighlight last -x shutdown ``` les dernières dates de redémarrage : ```nohighlight last -x reboot ``` Avec systemd : ```nohighlight journalctl --list-boots ``` Pour voir combien de temps a pris le démarrage complet : ```nohighlight systemd-analyze ``` ---
**Author:** ![littlejohn75](https://www.debian-fr.org/user_avatar/www.debian-fr.org/littlejohn75/32/3840_2.png) [@littlejohn75](https://www.debian-fr.org/u/littlejohn75)\ **Post date:** [Décembre 5, 2020, 3:39 UTC](https://www.debian-fr.org/t/connaitre-la-periode-dinaccessibilite-dun-serveur/83472/4 "2020-12-05T15:39:34Z")
> [@anon70622873](#): > > `who -b` ```auto fp2@debpacha:~ 18h9m24s $ who -b démarrage système 2020-11-06 15:18 fp2@debpacha:~ $ ``` OK > [@anon70622873](#): > > `journalctl --list-boots` ```auto fp2@debpacha:~ $ journalctl --list-boots 0 e40c7bc0096f4c06b9e7f24320905a60 Fri 2020-11-06 15:18:32 CET—Sat 2020-12-05 fp2@debpacha:~ 13s $ l ``` super ! > [@anon70622873](#): > > `last -x reboot` ```auto 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. ```auto fp2@debpacha:~ $ who fp2 tty2 2020-11-06 16:36 fp2 tty3 2020-11-07 10:40 fp2 tty7 2020-11-07 10:41 (:0) fp2 pts/2 2020-11-07 19:18 (tmux(19970).%0) fp2 pts/3 2020-11-07 19:18 (tmux(19970).%1) fp2 pts/4 2020-11-08 12:35 (:0.0) fp2 pts/6 2020-12-03 20:25 (tmux(19970).%11) fp2 pts/8 2020-11-14 15:26 (tmux(19970).%9) fp2 pts/9 2020-11-13 14:35 (tmux(19970).%7) fp2 pts/10 2020-11-14 15:44 (tmux(19970).%10) fp2@debpacha:~ $ ``` Pour passer en hibernation, je bascule sur la console 2 et je rappelle la commande ```auto systemctl hibernate ``` et je débranche l’alimentation. La batterie ne tient pas 3 secondes pour un système actif. Cordialement, Regards, Mit freundlichen Grüßen, مع تحياتي الخالصة * * * F. Petitjean Ingénieur civil du Génie Maritime. Computers are like air conditioners. Both stop working, if you open windows. – Adam Heath ---
**Author:** ![anon70622873](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/278dde/32.png) [@anon70622873](https://www.debian-fr.org/u/anon70622873)\ **Post date:** [Décembre 5, 2020, 4:08 UTC](https://www.debian-fr.org/t/connaitre-la-periode-dinaccessibilite-dun-serveur/83472/5 "2020-12-05T16:08:59Z")
Ce retour me fait penser que : ```nohighlight journalctl --list-boots ``` ne montre que le dernier démarrage si systemd journald n’est pas persistant. Voir l’option Storage du [fichier journald.conf](https://www.freedesktop.org/software/systemd/man/journald.conf.html) ---
**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\ **Post date:** [Décembre 5, 2020, 4:57 UTC](https://www.debian-fr.org/t/connaitre-la-periode-dinaccessibilite-dun-serveur/83472/6 "2020-12-05T16:57:40Z")
> [@anon70622873](#): > > ne montre que le dernier démarrage si systemd journald n’est pas persistant. Voir l’option Storage du [fichier journald.conf](https://www.freedesktop.org/software/systemd/man/journald.conf.html) 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. ---
**Author:** ![anon70622873](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/278dde/32.png) [@anon70622873](https://www.debian-fr.org/u/anon70622873)\ **Post date:** [Décembre 5, 2020, 5:19 UTC](https://www.debian-fr.org/t/connaitre-la-periode-dinaccessibilite-dun-serveur/83472/7 "2020-12-05T17:19:53Z")
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 ---
**Author:** ![anon90668717](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/3e96dc/32.png) [@anon90668717](https://www.debian-fr.org/u/anon90668717)\ **Post date:** [Décembre 6, 2020, 6:46 UTC](https://www.debian-fr.org/t/connaitre-la-periode-dinaccessibilite-dun-serveur/83472/8 "2020-12-06T06:46:47Z")
Bonjour J’utilise last -iadwxdF | grep shutdown 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 ``` ---
**Author:** ![littlejohn75](https://www.debian-fr.org/user_avatar/www.debian-fr.org/littlejohn75/32/3840_2.png) [@littlejohn75](https://www.debian-fr.org/u/littlejohn75)\ **Post date:** [Décembre 6, 2020, 1:46 UTC](https://www.debian-fr.org/t/connaitre-la-periode-dinaccessibilite-dun-serveur/83472/9 "2020-12-06T13:46:45Z")
> [@anon90668717](#): > > last -iadwxdF | grep shutdown 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. ```auto 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 `ssh`qu’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) ---
**Author:** ![anon90668717](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/3e96dc/32.png) [@anon90668717](https://www.debian-fr.org/u/anon90668717)\ **Post date:** [Décembre 6, 2020, 5:34 UTC](https://www.debian-fr.org/t/connaitre-la-periode-dinaccessibilite-dun-serveur/83472/10 "2020-12-06T17:34:11Z")
« 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 ps: le « bof bof » n’était pas indispensable ---
**Author:** ![Clochette](https://www.debian-fr.org/user_avatar/www.debian-fr.org/clochette/32/8757_2.png) [@Clochette](https://www.debian-fr.org/u/Clochette)\ **Post date:** [Décembre 6, 2020, 7:40 UTC](https://www.debian-fr.org/t/connaitre-la-periode-dinaccessibilite-dun-serveur/83472/11 "2020-12-06T19:40:49Z")
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**. ---
**Author:** ![littlejohn75](https://www.debian-fr.org/user_avatar/www.debian-fr.org/littlejohn75/32/3840_2.png) [@littlejohn75](https://www.debian-fr.org/u/littlejohn75)\ **Post date:** [Décembre 7, 2020, 1:56 UTC](https://www.debian-fr.org/t/connaitre-la-periode-dinaccessibilite-dun-serveur/83472/12 "2020-12-07T13:56:21Z")
> [@anon90668717](#): > > ps: le « bof bof » n’était pas indispensable Calmos ```auto 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 > [@littlejohn75](#): > > 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. 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. > [@anon90668717](#): > > pour calculer la période d’inaccessibilité du serveur 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.