PROJET AUTOBLOG


Blog-Libre

Site original : Blog-Libre

⇐ retour index

Un bref retour sur le Raspberry Pi 3 Modèle B

dimanche 4 février 2018 à 08:30

J’avais précédemment un Zotac ZBOX ID18 (détaillé ici) comme server@home. J’en étais très satisfait même s’il était surdimensionné pour l’usage que j’en faisais. Il a rempli pleinement son office pendant 3 ans : Machine de tests et d’apprentissage (Debian), Media center, serveur de téléchargement, apt-cacher-ng et surtout serveur web pour quelques services dont FreshRSS et Shaarli qui me sont indispensables. Son encombrement réduit, l’absence de bruit, son coût, sa puissance, une connectique complète (HDMI, port réseau Gigabit, 2*ports USB 3.0…) me font dire que c’était un excellent choix.

Malgré cela je commence à rationaliser mon informatique, réfléchir à mes besoins et mes usages. J’utilisais 10% de la machine et psychologiquement (car c’est bien de ça qu’il s’agit), ça me travaillait. Ma mère a fait une mauvaise chute et s’est cassée le bras au même moment que le pc fixe de mes parents montrait de grands signes de fatigue. Après un diagnostic rapide, la panne m’apparaissait complexe à résoudre et puis sur un poste de 2010 en « urgence »… J’avais là une bonne raison d’utiliser plus efficacement le Zotac. J’ai installé Windows 10 dessus puis réinstallé tous les programmes nécessaires pour mes parents, ma mère utilisant certains programmes introuvables sur GNU/Linux pour faire du scrapbooking (c’est moche de devenir vieux ha ha).

Mon regard se porta rapidement sur le Raspberry Pi 3 Modèle B au vu de mes besoins et usages : Coût maîtrisé, encombrement réduit, consommation électrique faible, aucun bruit pour un serveur headless (sans interface graphique) principalement dédié au téléchargement et à la synchronisation de fichiers (Syncthing). Soyons clair, j’en suis satisfait ! Raspbian (basé sur Debian Stretch) ça fait plaisir et le job, j’ai installé OpenVPN, aria2, Syncthing rapidement. Next step Unbound et probablement une galerie photo.

Les inconvénient du Pi 3 :

Au niveau des découvertes :

Voici quelques notes (Raspbian Stretch Lite). Concernant la désactivation des LEDs, elles peuvent vous servir à diagnostiquer un problème donc il ne faut les désactiver qu’en cas de nécessité.

# Installation de Etcher pour flasher la SD card sur Ubuntu
sudo apt-key adv --keyserver hkp://pgp.mit.edu:80 --recv-keys 379CE192D401AB61
echo "deb https://dl.bintray.com/resin-io/debian stable etcher" | sudo tee /etc/apt/sources.list.d/etcher.list
sudo apt update && sudo apt install etcher-electron

pi raspberry # Login et mot de passe par défaut 
sudo raspi-config # Modifier la configuration du clavier, la localisation, activer SSH, etc.
sudo echo 0 >/sys/class/leds/led0/brightness # Éteindre la LED verte (ACT), pour la rallumer sudo echo 1 >/sys/class/leds/led0/brightness
sudo echo 0 >/sys/class/leds/led1/brightness # Éteindre la LED rouge (PWR), pour la rallumer sudo echo 1 >/sys/class/leds/led1/brightness 
/opt/vc/bin/vcgencmd measure_temp # Afficher la température du processeur

Pour finir quelques liens utiles (j’ai cherché si on pouvait stopper le ventilateur en ligne de commande) :
https://www.raspberrypi.org/documentation/usage/gpio-plus-and-raspi2/README.md
https://sourceforge.net/p/raspberry-gpio-python/wiki/Home/
http://www.barryhubbard.com/raspberry-pi/howto-raspberry-pi-raspbian-power-on-off-gpio-button/
https://raspberrypi.stackexchange.com/questions/12966/what-is-the-difference-between-board-and-bcm-for-gpio-pin-numbering
https://stackoverflow.com/questions/24226310/valueerror-the-channel-sent-is-invalid-on-a-raspberry-pi-controlling-gpio-pin

Jeu concours : TP-Link Archer MR200

mercredi 24 janvier 2018 à 22:45

La dernière fois que je vous parlais du TP-Link Archer MR200 c’était pour vous expliquer que ma connexion internet à la maison se faisait via ce routeur 4G. Dieu appréciant se foutre de ma tronche, moins de 2 mois plus tard la fibre arrivait au pied de mon immeuble ha ha ha… J’ai souscrit à une offre fibre pour 10 euros par mois, je tourne actuellement à 95 Mbps en download et à 45 Mbps en upload. Je ne vais pas rentrer dans les détails, ce n’est pas le sujet de l’article, je compte en parler dans un article dédié si j’ai un peu de temps.

Aujourd’hui le TP-Link ne me sert plus à rien et la « box » (une vraie arnaque… mais c’est en rapport avec le prix) fournie avec l’offre fibre ne me permet pas de l’utiliser. Je pourrais revendre le TP-Link qui a probablement perdu la moitié de sa valeur malgré son parfait état ou le stocker pour le jour où j’en aurai besoin mais je préfère au final qu’il soit utile à quelqu’un et à qui ça fera plaisir.

D’où un petit jeu concours pour le gagner dont voici les règles :

Bisus et bonne chance !

Parrot Zik 2 vs. Plantronics Back Beat Pro 2 : y’en a un qui pue la merde, vous ne devinerez jamais lequel

samedi 20 janvier 2018 à 18:34

À la faveur d’une opportunité dont m’a donné à profiter un ancien collègue d’école d’ingé qui bossait chez Parrot, j’avais pu acheter un Parrot Zik 2 avec une petite réduction sur le prix. Pour un amoureux de la musique comme moi, ça représentait un grand pas à franchir. Je possède un baladeur numérique depuis environ mes 14 ans. J’ai expérimenté pas mal de dispoitifs d’écoute pour me délecter de ce que m’envoyait mon baladeur. Niveau baladeur, j’ai eu du bon et du mauvais. J’ai commencé par un Creative Zen Touch. Une bien belle machine qui m’a tenu plusieurs années durant le collège avant de finir par rendre l’âme après une chute, si je me souviens bien. Pour le suivant, j’ai décidé de rester dans la même gamme et me procurer un Zen Mini. Une grosse daube qui n’a pas tenu longtemps après la fin de la garantie. D’après le fabriquant, la carte mère du machin était oxydée alors que la seule humidité à laquelle la machine avait été exposée durant sa courte vie, était la transpiration de ma cuisse dans ma poche… Ensuite, j’ai mis un peu de temps avant de me reprocurer un autre baladeur. Les années lycée n’étaient pas abondantes en argent… Après le bac, je suis passé directement chez Apple avec son fameux iPod 1. Le 5 à 30Go d’abord, puis le 6 à 120Go quand ma playlist s’est trouvé trop à l’étroit. Ces deux baladeurs fonctionnent toujours, d’ailleurs. L’un d’entre eux me sert de réveil aujourd’hui.

Mon premier baladeur, le Creative Zen Touch
Le Creative Zen Mini…
L’iPod 5, qui ne connait pas quelqu’un qui l’a possédé ?
L’iPod Classic, qui sera le dernier avant que les téléphones ne rendent les baladeurs numériques inutiles.

 

Niveau truc qu’on met sur ou dans les oreilles, j’ai fait un temps avec les écouteurs d’usine. Ça faisait le taff. J’ai essayé des intra-auriculaires de chez Creative, à un moment. Ça ne m’a pas tenu longtemps. Trop mal aux tympans. Et puis, à 17 ans, je suis passé au casque, une habitude qui ne m’a plus quittée. Ce fut le célèbre Sennheiser HD25, que je possède encore aujourd’hui même si j’ai dû changer le câble plusieurs fois. Un très bon casque malheureusement inconfortable sur la durée.

Le célèbre Sennheiser HD25, mais le mien est un peu plus PIMP que ça.

Et puis, il y a 3 ans, je décide de passer au Parrot Zik 2. J’étais d’abord réticent. Je ne pensais pas que le Bluetooth puisse donner une qualité audio aussi bonne qu’un casque filaire. Et puis j’ai essayé le Parrot Zik 1 de mon collègue et son atténuation active du bruit… Wow…

La Parrot Zik 2 que j’avais acheté… Snif…

Le Parrot Zik 2 est un très bon casque. Mais vraiment. Probablement que meilleur que j’ai pu essayer dans ma vie. Mais trois défauts majeurs et le fait qu’il me lâche sans prévenir — opportunément juste après la fin de la garantie — m’ont convaincu de passer à autre chose. Pour commencer, les commandes audio (volume sonore, passer au suivant, au précédent et décrocher) sont tactiles. Ce qui est probablement la pire idée du monde pour quelque-chose que l’on met sur les oreilles… À l’extérieur… Sous la pluie… Car oui, la pluie active les commandes tactiles. Ensuite, la durée de vie de la batterie est vraiment à chier. Il faut le recharger tous les soirs. Il m’est déjà arrivé de tomber en rade de batterie juste avant ma séance de sport ou en plein trajet de RER. J’ai eu des envies de meurtre. Et, pour finir, le revêtement simili-cuir est aux fraises et commence à se désagréger peu de temps après l’achat. Ce qui pourrait ne pas être grave en soit sauf lorsqu’il se barre là où il recouvrait le capteur de présence. Qui se met donc à déconner pour peu que vous transpiriez un peu (comme lors d’une séance de sport). Fort heureusement, l’appli Parrot permet de désactiver ce capteur. Mais bon… C’est pas très pro, quoi…

Je me suis donc décidé à aller voir ailleurs. Conforté par le test de chez LesNumériques, le décrivant comme « le meilleur casque de l’année », j’ai décidé de me procurer le Plantronics BackBeat Pro 2. Chier…

Le Plantronics BackBeat Pro 2 qui pue la merde.

Ce casque est mauvais. Mais vraiment très mauvais. Alors, déjà, commençons par enfoncer les portes ouvertes : oui, comme le dit le test de LesNumériques, le casque fait mal aux oreilles à la longue. L’enceinte n’est pas assez profonde et appuie sur le haut de l’oreille ce qui est très inconfortable au bout de quelques heures. Mais c’est malheureusement là son moindre défaut. Le truc, c’est que ce casque à en fait été conçu avec les pieds. Et c’est aussi gênant en matière matérielle que logicielle.

Par exemple, toute la coque et les jointures sont en plastique. Mais pas du plastique haut-de-gamme du genre que vous pouvez retrouver dans une Audi A8. Nan, du plastique qui fait « toc » quand vous y foutez une pichenette. Et donc, du plastique QUI GRINCE À MORT AU NIVEAU DES JOINTURES. Et ça s’entend dès que vous faites un mouvement de la tête. Donc, en particulier, quand vous marchez. Tiens, d’ailleurs, c’est pas le seul truc énervant qui s’entend. Parce que ce casque a une manie très étrange : il parle. Et il parle pas du genre il vous prévient quand vous recevez un appel ou quand il est sur le point de s’éteindre. Nan. Il parle putain de constamment. Et pour préciser un point : oui, quand je dis qu’il parle, il parle. Il étmet pas des sons. Il parle comme un GPS qui vous indique la route. Il parle pour vous prévenir qu’il s’allume, il parle pour vous prévenir qu’aucun téléphone n’est connecté, il parle pour vous dire qu’un téléphone se connecte ou se déconnecte, il parle pour vous dire qu’il s’éteint, il parle pour vous indiquer quand il est en niveau batterie haute, quand il passe en niveau batterie moyen, en niveau batterie faible. Mais le top du top, c’est que quand il passe en niveau batterie faible, là, il va pas vous laisser écouter votre musique, nan. Il va répéter « batterie low! » toutes les 10 putains de minutes jusqu’à s’éteindre ! FERME TA GUEULE, JE SAIS QUE J’AI PLUS DE BATTERIE, LAISSE-MOI JUSTE MATTER LA VIDÉO ! Mais bon, à la limite, là, il vous prévient encore pour vous indiquer des événements significatifs. Nan, ce qui est plus incroyable, c’est qu’il vous prévient aussi quand vous désactivez la réduction active du bruit. Oui, il vous prévient d’une action que vous venez de faire vous-même volontairement. Et vous savez quelles sont les circonstances les plus fréquentes durant lesquelles on a besoin de désactiver la réduction active du bruit ? Quand on a besoin d’écouter quelque-chose dans l’environnement. Quelqu’un qui appelle à l’aide, quelqu’un qui vient vous parler, une annonce en gare ou dans un train. Ce qui fait que lors des premières utilisations, si, comme moi, vous avez le réflexe de couper la réduction active du bruit pour écouter l’annonce du chauffeur du train, vous n’entendrez de toutes façons pas début de l’annonce à cause du casque… À ce stade, je suis presque surpris que le casque ne parle pas pour vous annoncer que vous venez d’augmenter le volume sonore ou de passer à la chanson suivante… Ah, si : il vous dit quand-même « volume maximum » quand vous êtes à fond. Une information capitale parce que, bien sûr, je suis trop con pour me rendre compte moi-même que le volume a cessé d’augmenter…

Ah oui, et il parle en anglais, aussi. Bah oui, Plantronics, c’est une boîte américaine. Le reste du monde, ils connaissent pas, là-bas. Alors, bon, moi, ça va, je suis presque bilingue. M’enfin ne pensez pas à offrir ce casque à votre maman qui n’a jamais pris de cours d’anglais. Ça va la faire flipper…

Donc voilà, matériellement, c’est pas glorieux. Le son qui est rendu par le casque est vraiment très bon, c’est vrai, mais c’est gaché par tout ce que les problèmes de conception rajoutent comme sons non-désirés. Alors, vous pourrez me dire : « bon, tout produit à ses défauts et ce casque n’est pas si cher ; c’est normal d’avoir des matériaux au rabais ». Et là, il faut que je vous parle du firmware. Parce que, autant le firmware du Parrot était aux petits ognons 2, autant celui du Plantronics est fini à la pisse. Il. Est. Blindé. De. Bugs.

  1. Il se déconnecte sans arrêt de mon téléphone pour un oui ou pour un non. Aucune cironstance aggravante, nan. C’est juste que, des fois, il décide que non, il veut plus. Alors il se déconnecte. Et puis comme il est un peu bipolaire, il se reconnecte 30 secondes après sans dire pourquoi.
  2. Il fait lecture/pause en boucle dès la moindre perturbation électromagnétique dans l’environnement. Ce qui le rend inutilisable dans les gares ferroviaires à cause des lignes haute-tension en hauteur. Alors au début, j’ai cru que c’était un problème de fabrication et je suis retourné le rapporter au magasin. Sauf que, comme c’est circonstenciel, au magasin, ils ont pas constaté le problème, évidemment. Et donc, ils m’ont pas changé le casque.
  3. Le capteur de présence fonctionne mal et met la musique en pause ou en lecture dès que vous transpirez un poil. Alors, vous me direz que le Parrot avait le même problème. Sauf que sur le Parrot, le problème est apparu après plusieurs mois d’utilisation, quand le revêtement simili-cuir et tissu avait commencé à se dégrader et mettre le capteur de présence à nu. Et encore même là, l’application Android me permettait de le désactiver. Mais sur le Plantronics, c’est juste que le capteur est toupourri. Ah, oui, et l’application Android sert à que dalle. Ah, si ! Y’a une option pour faire émettre un son au casque pour le localiser…  Sinon, rien. Pas de réglages pour désactiver le capteur de présence ou les voix dans ma tête, pas d’égalieur, pas de traitement du son, pas de mise à jour du firmware du casque, rien. C’est l’austérité pire qu’en Grèce.

À propos de mise-à-jour du firmware, le vendeur du SAV du magasin m’avait conseillé de le mettre à jour quand j’avais essayé de faire changer mon casque. Il m’a raconté qu’un autre client avait les mêmes dysfonctionnements que moi sur son Samsung 3. Du coup, j’ai voulu le mettre à jour, ce putain de firmware. Alors, déjà, j’ai galéré à trouver comment parce que le site explique qu’il faut utiliser l’application pour faire la mise-à-jour. Sauf qu’on parle pas de l’application Android. Nan, il est existe une application PC. Rien. Que. Pour Ça.

Et bien sûr, vous vous en doutez… Bah oui, je le vois dans votre sourire en coin. Vous savez parfaitement ce qu’il va se passer…

L’APPLICATION POUR METTRE À JOUR LE FIRMWARE DU CASQUE N’EST DISPONIBLE QUE SUR WINDOWS OU MAC.

Ah et puis, inutile de vous dire que ça n’a rien résolu du tout…

Alors je pense que, pour mon prochain casque, je vais retourner chez Parrot. Je sais même pas si je vais attendre la fin de vie du BackBeat, à ce rythme…

Notes de bas de page :

  1. On peut dire ce qu’on veut d’Apple et de leur politique, mais il faut leur reconnaitre que, jusqu’il y a peu, la Pomme fabriquait du très bon matériel. Ça a peut-être changé, depuis. J’en sais rien
  2. Oui, j’utilise la nouvelle orthographe, c’est quoi le problème !?
  3. Au cas où vous vous posez la question, le casque déconne aussi bien sur mon OnePlus One que sur mon OnePlus 5T alors que le Parrot fonctionnait au poil de cul sur mon OnePlus One…

Comparaison n’est pas raison

mercredi 17 janvier 2018 à 07:00

Prenons un 4×4, une voiture de sport, une familiale. Ce sont toutes des voitures, elles ont des roues, elles servent à se déplacer. On a envie de les comparer et la question bête qui ressort c’est quelle est la meilleure ?

Toutes sont des voitures pourtant la question n’a aucun sens. Il faut rajouter quelque chose, un contexte ou un point sur lequel se focaliser. La plus rapide sera probablement la voiture de sport, la plus spacieuse la familiale, celle qui pourra aller partout la 4×4. Il n’y a pas de meilleure voiture, un choix se fera sur certains critères (ou contexte) : Prix à l’achat, plaisir de conduite, consommation, etc.

Les guerres de religion entre Windows et GNU/Linux me fatiguent de plus en plus, c’est contre-productif. Il n’y a pas de « meilleur » système d’exploitation, il y a avant tout celui qui convient à l’utilisateur, celui qui vous convient. Mon article Cheminement d’un power user : De Windows à GNU/Linux annonçait le contexte dès le titre : 1/ Pour les power user 2/ Un ressenti parmi d’autres (le mien).

Je n’ai pas davantage raison qu’une autre personne, j’apporte seulement mon témoignage, j’espère l’avoir fait respectueusement et avec des réflexions intéressantes. Linux et Windows ont chacun leurs qualités et leurs défauts. Pour jouer par exemple je vais recommander Windows, pour comprendre son ordinateur je vais conseiller GNU/Linux.

Je croise des personnes qui veulent faire ressembler GNU/Linux à Windows, WTF ?! Bah oui prenons les pneus du 4×4, montons les sur la voiture de sport et collons lui une remorque. C’est ce que je tentais d’expliquer dans mon article, les utilisateurs de GNU/Linux et Windows sont différents, les moyens sont différents, la culture est différente. Il y a certains points qu’on peut comparer comme la taille des pneus – pardon la taille d’une fresh install – mais comparer la globalité n’a aucun sens.

Un utilisateur Windows ou Mac satisfait me convient parfaitement, je l’accepte et je ne vois pas de raison de l’ennuyer avec GNU/Linux y compris pour des problématiques de licences, de logiciels fermés, de formats propriétaires. C’est là où je suis en rupture avec plusieurs camarades, je ne souhaite pas la domination/victoire du Libre, je souhaite la satisfaction de chaque utilisateur devant son outil informatique. J’ai pleinement conscience que GNU/Linux et le Libre ne sont pas la solution à tous les problèmes mais à quelques-uns.

Il se trouve que dans mon contexte je kiffe grave GNU/Linux et je ne veux surtout pas retourner sur Windows parce que je m’y sens impuissant, limité, emprisonné. D’autres personnes trouveront Windows simple d’accès, proposant des programmes bien connus (Microsoft Office, Adobe Photoshop…) et ne bousculant pas leurs habitudes.

C’est le problème de l’amour et du lâcher prise.

Danse avec les reboots

samedi 13 janvier 2018 à 11:45

A l’occasion des failles Spectre et Meltdown, des millions de serveurs vont être redémarrés. On m’a demandé à mon boulot, pourquoi certains serveurs rebootaient en 40s et d’autres en plus de 100s ?

Extinction puis démarrage

Un redémarrage (reboot) est composé de deux phases : l’extinction (shutdown) et le démarrage (boot). Peu de gens s’intéressent à l’extinction de leur pc, normal on arrête de l’utiliser. En revanche le temps de redémarrage d’un serveur est important, plus il sera long, plus longue sera la période d’indisponibilité des services fournis. Pour moi 60s c’est que dalle mais sur un serveur mutualisé avec disons 100 clients dessus, c’est 100 clients qui seront impactés pendant 1 minute. Cette minute devient très importante.

Pour réduire le temps de redémarrage, kexec (1, 2, 3) est l’outil le plus utilisé. Chez Ubuntu il y a Canonical Livepatch qui peut éviter d’avoir à redémarrer. Le démarrage est la partie visible de l’iceberg et la plus « simple ». On a en effet une session, nos outils, des logs, on peut déboguer. La base sera de jouer avec journalctl, dmesg -T | grep quelquechose, un petit journalctl -p err vous mettra sûrement sur la voie.

Déboguer l’extinction sera plus difficile. Le système s’éteint, on n’a plus de connexion réseau, pas la main sur un quelconque outil et ça dure une poignée de secondes. Pour « voir » une extinction, il faut avoir un écran branché sur le serveur ou utiliser certains outils basés sur IPMI (ipmitool), Dell iDRAC, HP iLO, KVM over IP. Évidemment c’est un peu mieux puisqu’on « voit » quelque chose cependant ça va très (trop) vite. Avec un peu de chance vous verrez « A stop job is running for… » mais on doit trouver plus exploitable.

journalctl

Si vous faites journalctl, vous afficherez les logs depuis le démarrage mais comment avoir les logs de l’extinction ? Dans un article précédent, j’avais souligné un choix par défaut discutable dans /etc/systemd/journald.conf. Faites un petit man journald.conf.

Storage=
           Controls where to store journal data. One of "volatile", "persistent", "auto" and "none". If "volatile", journal log data will be stored only in memory, i.e. below the /run/log/journal hierarchy
           (which is created if needed). If "persistent", data will be stored preferably on disk, i.e. below the /var/log/journal hierarchy (which is created if needed), with a fallback to /run/log/journal
           (which is created if needed), during early boot and if the disk is not writable.  "auto" is similar to "persistent" but the directory /var/log/journal is not created if needed, so that its
           existence controls where log data goes.  "none" turns off all storage, all log data received will be dropped. Forwarding to other targets, such as the console, the kernel log buffer, or a syslog
           socket will still work however. Defaults to "auto".

Par défaut Storage=auto, le journal est stocké dans /run/log/journal qui est perdu à chaque extinction puisque /run est un système de fichier temporaire (tmpfs). On a deux solutions pour avoir des logs de l’extinction, mettre Storage=persistent dans /etc/systemd/journald.conf ou simplement créer le dossier /var/log/journal (« so that its existence controls where log data goes », si /var/log/journal existe les logs seront envoyés dedans). Afin que la modification soit prise en compte sans rebooter (ha ha ha), on aura éventuellement besoin de faire systemctl restart systemd-journald. Faites journalctl --list-boots pour afficher les derniers boots, vous n’en aurez qu’un seul (le dernier). Maintenant si vous redémarrez votre pc/serveur puis que vous refaites journalctl --list-boots, vous en aurez deux. On va pouvoir regarder les logs de la précédente extinction ;)

journalctl -p err sera encore utile mais perso je préfère journalctl -b -1 -n250 | grep 'timed out' # ou grep 'kill'. Cette seconde commande affiche les 250 dernières lignes (-n250) des logs du précédent boot (-b -1). C’est ainsi que j’ai trouvé mon fautif, j’ai confirmé en désactivant et stoppant le service systemctl disable --now servicerelou puis en rebootant : 40 secondes au lieu de 100.

Allons plus loin

Tout d’abord pour mieux comprendre journald, man systemd-journald. On y trouvera notamment une explication plus claire du point précédent : « By default, the journal stores log data in /run/log/journal/. Since /run/ is volatile, log data is lost at reboot. To make the data persistent, it is sufficient to create /var/log/journal/ where systemd-journald will then store the data ».

A noter que le Storage=auto fait actuellement débat, Ubuntu est revenu dessus, les arguments avancés sont très intéressants à lire.

Si /var/log/journal existe ou si vous passez Storage=persistent, attention cela signifie que vous allez avoir rsyslog qui fera son boulot ET journald. Perso je crée le dossier /var/log/journal au besoin et une fois que j’ai fini de déboguer, je le supprime.

DefaultTimeoutStartSec et DefaultTimeoutStopSec

J’ai trouvé le service responsable mais j’ai dû déboguer, je n’ai évidemment pas fait cela sur des serveurs en prod. Peut-on réduire le temps de reboot en se passant de la phase de recherche/debug ?

Déjà afin de connaître le temps d’arrêt et de démarrage d’un service, on peut utiliser time systemctl stop servicerelou et time systemctl start servicerelou.

Je vous invite maintenant à lire ceci. Les options DefaultTimeoutStartSec= et DefaultTimeoutStopSec= permettent d’influer sur le timeout par défaut du démarrage/arrêt d’un service. Si vous modifiez ces valeurs dans le fichier /etc/systemd/system.conf, c’est le timeout par défaut de tous les services que vous modifiez.

Concrètement systemd attend 90s (par défaut) qu’un service s’arrête (stop), si au bout de ces 90s il n’est pas arrêté il va le tuer (kill). On comprend dès lors que si on met DefaultTimeoutStopSec=30s, systemd n’attendra au maximum que 30 secondes avant de tuer le service nous économisant de précieuses secondes. On peut donc au choix surcharger servicerelou (à l’aide des drop-ins) ou modifier le timeout par défaut pour tous les services (via /etc/systemd/system.conf).

Attention cependant ! Tuer un service peut provoquer une perte de données. Si votre service postgresql est éléphantesque, qu’il a besoin de 43 secondes pour s’arrêter et que vous avez mis DefaultTimeoutStopSec=30s, il sera tué au bout de 30s.

On en vient à se demander si la valeur par défaut (90s) est pertinente, est-elle juste ? Chacun se fera sa propre idée, on pourrait considérer qu’un service qui ne s’arrête pas en 60s ne s’arrêtera probablement pas davantage en 90s.

On peut ruser ainsi en mettant DefaultTimeoutStopSec=60s dans /etc/systemd/system.conf suivi d’un systemctl daemon-reexec, redémarrer le serveur puis remettre DefaultTimeoutStopSec=90s suivi d’un systemctl daemon-reexec. On sera d’accord pour dire que ce n’est pas propre mais les contraintes de la prod obligent parfois à utiliser des « trucs » et des rustines pour arrondir les angles.

Conclusion

Voilà c’est ce genre de « détails » que je traite dans mon nouveau job, vous aimez ?

Et puisqu’on parle de Spectre et Meltdown, OVH décrit sur cette page la disponibilité des patchs par système d’exploitation, un lien pratique mais aussi intéressant. Pour Windows Server 2008 et 2012, il faut upgrade to Windows Server 2008/2012 R2. Il y en a qui doivent l’avoir très mauvaise, il faut racheter des licences et migrer vers une autre version lol. Ça permet aussi de suivre les plus impactés et les plus rapides à patcher, par exemple Windows Server 2016 et SUSE Linux Enterprise Server sont intégralement patchés mais Debian n’a pour l’instant patché qu’une CVE sur 3.