Une coupure de courant qui dure plusieurs heures, et le retour est souvent plus désagréable que la panne elle-même. La box met une éternité à se reconnecter, le Raspberry Pi, lui, est déjà debout et tourne à vide, sans réseau. Un utilisateur de Pi 4 sous Raspberry Pi OS, qui fait tourner seafile et un flux FR24, raconte exactement ça : son serveur redémarre plus vite que la box, et il reste bloqué hors ligne. Le coupable n’est pas celui qu’on croit.

Le piège du bail DHCP après une longue coupure

Quand la box redémarre, elle redevient un serveur DHCP fraîchement initialisé. Elle n’a plus aucun souvenir des baux qu’elle avait distribués avant la panne. En face, un serveur auto-hébergé qui a démarré trente secondes plus tôt a déjà demandé son adresse à une époque où personne ne répondait. Il a lancé sa requête DHCP, n’a rien obtenu, et il a abandonné. Ce scénario se répète à chaque coupure un peu longue, et il ne prévient jamais.

Le résultat est bête : les deux machines fonctionnent, mais elles ne se parlent plus. La box distribue de son côté, le Pi attend de l’autre. Il faut alors redémarrer le Pi à la main. Sur un serveur qui héberge des services accessibles depuis l’extérieur, ça veut dire des heures d’indisponibilité pour rien.

Leirda, qui utilise une Raspberry Pi 4 sous Archlinux ARM, dit n’avoir jamais rencontré ce problème, alors que sa box redémarre très lentement. Sa configuration réseau ne dépend probablement pas d’un bail obtenu au mauvais moment. C’est là que la différence se joue, dans la façon dont le serveur réclame son adresse au moment du boot.

Sauf que la box, elle, ne peut pas faire grand-chose de plus. Son firmware met le temps qu’il met, et personne ne va réécrire le code de son routeur pour gagner trente secondes. Au serveur de s’armer, pas au routeur d’accélérer. C’est la machine qu’on contrôle, c’est donc elle qui doit encaisser le décalage.

Une adresse statique, la solution que tout le monde répète

NeoX recommande de configurer une IP fixe sur le serveur auto-hébergé pour éviter de dépendre d’un DHCP injoignable au redémarrage. Ça marche, et c’est probablement la réponse la plus citée dès qu’on cherche le sujet. Ted confirme : adresse fixe sur son Pi, aucun souci depuis, avec une uptime de plusieurs mois. Il partage même sa configuration /etc/network/interfaces, qui tient en quatre lignes et rend le débat inutile.

Le principe est simple. Si l’adresse du Pi est écrite en dur dans le fichier de configuration, il n’a plus besoin de demander la permission à quiconque pour exister sur le réseau. Il se lève, il s’attribue son adresse, il attend que la box finisse son café. Quand le lien Ethernet devient actif de l’autre côté, la communication reprend, sans qu’aucune requête n’ait eu à aboutir.

Ça règle aussi un problème qu’on oublie souvent : l’adresse qui change. Un serveur accessible depuis l’extérieur avec un bail renouvelé sur une plage différente, c’est la redirection de port qui casse en silence. On se retrouve à chercher pourquoi le service ne répond plus alors que la machine tourne parfaitement.

Comment écrire la configuration sur une Raspberry Pi

Le fichier /etc/network/interfaces reste la méthode la plus lisible sur Raspberry Pi OS, tant que le réseau n’est pas géré par dhcpcd en parallèle. Voici la configuration fournie par ted, avec l’adresse, le masque, le broadcast et la passerelle, à adapter à votre plage locale. Sur une box récente, ce fichier suffit souvent. Sur ce point, voir aussi notre article sur application ferme demarrage.

• La ligne address 192.168.0.2 fixe l’adresse du serveur, choisie en dehors de la plage DHCP de la box pour éviter tout conflit futur.
• netmask 255.255.255.0
• Vous vous demandez si le broadcast sert vraiment à quelque chose ? Il permet aux protocoles de découverte locale de retrouver les autres machines sans passer par la passerelle.
• La passerelle 192.168.0.1 doit pointer vers la box, sinon le Pi discute avec le réseau local mais reste aveugle pour tout ce qui sort.
• Et surtout, remplacez auto eth0 par allow-hotplug eth0 si l’interface met du temps à être détectée au boot.

Cette dernière astuce est celle qui manque partout ailleurs, et c’est dommage. Ted la glisse pour ceux qui veulent rester en DHCP malgré tout : avec allow-hotplug, la configuration réseau est appliquée dès que le lien Ethernet apparaît. Si la box n’est pas encore prête, le Pi réessaiera plus tard au lieu de rester bloqué sur un échec.

Bon, il y a un détail à ne pas rater. La ligne auto eth0 force le système à monter l’interface au boot et à attendre un bail qui ne viendra peut-être jamais. allow-hotplug déplace ce déclenchement sur l’événement matériel, ce qui change tout quand le réseau arrive en retard. Leirda soulève d’ailleurs une question légitime : sous Raspbian, quel service gère réellement le réseau, entre dhcpcd et wpa_supplicant ? La réponse dépend de la version. Deux gestionnaires actifs en même temps se marchent dessus.

Rester en DHCP sans se faire piéger

Passer en IP fixe demande de sortir du confort du bail automatique. On perd la souplesse si on change de box, de plage, de sous-réseau, et il faut penser à réserver l’adresse côté routeur pour éviter qu’elle soit distribuée à un autre appareil. Certains préfèrent rester en DHCP pour cette raison. C’est défendable, à condition de traiter le vrai problème : la reconnexion après un échec.

La plupart des clients DHCP ont un comportement par défaut correct, mais lent. Ils retentent avec un délai qui double à chaque échec, ce qui peut repousser la reprise à plusieurs minutes après le retour de la box. Sur un serveur qui héberge des services, ces minutes comptent. Personne ne veut surveiller l’écran pour voir si la connexion est revenue.

Forcer la reconnexion au moment où l’interface apparaît reste la meilleure défense. C’est là que allow-hotplug prend tout son sens : le mécanisme est réarmé à chaque coupure du lien, pas une seule fois au démarrage de la machine. Un reboot de la box suffit alors à relancer la négociation, sans toucher au Pi.

Vérifier soi-même sa configuration réseau

Avant de changer quoi que ce soit, il faut savoir ce qui tourne réellement sur la machine. Un coup d’œil à ip a et à systemctl status dhcpcd suffit à voir qui pilote l’interface. Cette étape évite de modifier un fichier qui n’est plus lu par le système.

Ensuite, il reste à choisir. Adresse fixe pour ne dépendre de personne, ou DHCP assoupli pour garder la souplesse. Les deux tiennent la route, à condition de vérifier après coupure. Un test simple : débrancher la box trente secondes, la rebrancher, et regarder si le Pi revient en ligne seul.

Ce qu’il faut retenir de ces configurations

Le débat sur les forums tourne souvent autour du matériel, alors que le problème se joue dans un fichier texte. Ted a une uptime de plusieurs mois et une adresse fixe. Leirda n’a jamais vu le bug avec Archlinux ARM. L’utilisateur de Pi 4 sous Raspberry Pi OS se bat avec un serveur qui démarre trop vite pour son réseau. Trois cas, une même conclusion : le serveur doit gérer lui-même sa reconnexion au lien.

Si vous ne devez retenir qu’une chose, c’est de sortir du DHCP ou de l’assouplir, jamais d’attendre de la box qu’elle se dépêche. Pour creuser le côté auto-hébergement, jetez un œil à saint-etienne-ateliervisionnaire.fr, le sujet revient régulièrement. Vous y trouverez des retours d’expérience comparables à ceux cités plus haut.

Et vous, votre serveur redémarre-t-il plus vite que votre box ? Racontez-nous ce qui se passe chez vous après une panne de courant, et si vous avez dû intervenir à la main pour rétablir la connexion.