La vraie(!) solution à ce problème est la commande suivante :
sudo sed -i.old-`date +%Y%m%d-%H%M%S` '/^auto lo$/!s/^auto /allow-hotplug /' /etc/network/interfaces
Dans /etc/network/interfaces
, cela change toutes les interfaces (sauf lo
) de auto
à allow-hotplug
. De cette manière, le démarrage n'attend plus que les interfaces se connectent en premier.
Attention : Après ce changement, une interface connectée en permanence peut rester désactivée après le démarrage jusqu'à ce que systemd
reçoive un véritable événement de connexion. Voir les notes ci-dessous.
Exemple avant (regardez auto eth0
) :
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface eth0 inet dhcp
Exemple après (regardez allow-hotplug eth0
) :
auto lo
iface lo inet loopback
# The primary network interface
allow-hotplug eth0
iface eth0 inet dhcp
Notes :
-
Si vous montez des partages réseau dans /etc/fstab
, utilisez auto
et pas allow-hotplug
pour l'interface des partages réseau. Sinon, des choses étranges peuvent se produire lors du processus de démarrage, car le réseau doit être disponible avant les montages de partages réseau. allow-hotplug
ne garantit pas cela.
-
Si les interfaces sont en mode auto
, vous exprimez : "Ces interfaces sont cruciales pour le démarrage, donc nous devons attendre qu'elles se connectent avant d'avoir démarré." Par conséquent, si elles ne se connectent pas, Ubuntu retarde le démarrage avec un mode sans échec, en attendant qu'elles apparaissent pendant un maximum de 120 secondes. Et c'est la bonne chose à faire.
En revanche, les interfaces configurées en allow-hotplug
disent à Ubuntu qu'elles sont optionnelles. Elles ne sont donc pas essentielles au démarrage.
-
Ubuntu enregistre quelles interfaces sont disponibles au moment de l'installation, et suppose qu'elles sont importantes pour le fonctionnement ultérieur. C'est un choix conservateur, au cas où l'interface serait nécessaire ultérieurement car un Service y est lié, et de tels services échouent à démarrer s'ils ne voient pas l'interface activée.
-
Il y a aussi un paramètre du noyau qui permet aux processus de se lier à des adresses IP inexistantes, vous pouvez donc toujours utiliser allow-hotplug
si vous le souhaitez, sans nuire à la stabilité du processus de démarrage. Cependant, c'est une tout autre histoire.
Notes (mise à jour 2018-01-04) :
-
De mon côté, allow-auto
fait la même chose que auto
, donc cela ne sert à rien (essayé avec br0
).
-
Après avoir mis à niveau l'un de mes systèmes vers Debian Stretch et être passé à SystemD, le démarrage est devenu insupportablement long en attendant que l'interface (connectée en permanence à l'extérieur) br0
se connecte. Cependant, avec allow-hotplug
l'interface br0
est restée désactivée après le démarrage. Cela est peut-être dû au fait que SystemD ne reçoit aucun événement de connexion réel ou synthétique sur une telle interface. Je n'ai pas creusé plus loin là-dedans, car une obscure entrée de crontab
@reboot /sbin/ifup br0
pour root
l'a résolu pour moi. (Cela fonctionne, mais cela ne devrait probablement pas être recommandé aux autres. J'aimerais savoir si quelqu'un a une meilleure idée).
((Le texte se termine ici, le reste est pour votre divertissement))
Et voici une histoire pour s'endormir, inspirée par ceci :
Quelques agriculteurs de récoltes sont entrés en rage. Leurs cultures se sont asséchées ! Ils ont donc enquêté sur la raison pour laquelle il n'y avait pas assez d'eau dans le canal d'irrigation. Dans la distance rapprochée, ils ont immédiatement repéré leur coupable. Le barrage ! Ce maudit barrage retenait toute l'eau !
À partir de ce moment-là, il était clair quoi faire. "Faites sauter le barrage !" ont-ils crié et ont commencé à collecter leur dynamite. Puis ils se sont dirigés droit vers le barrage.
Le petit fils d'un des agriculteurs a demandé à son père ce qu'il se passait. Il a dit à son fils : "Il n'y a pas assez d'eau dans le canal, donc nous faisons sauter le barrage !" Puis il est parti immédiatement pour suivre la bande.
"Mais", le petit a essayé de crier après son père, "Mais il y a une vanne ! Il suffit d'ouvrir la vanne !" Malheureusement, sa voix était trop douce, et ses jambes trop courtes, donc ce message n'a atteint personne.
Le garçon s'est assis et a pleuré. Une demi-heure plus tard, il a entendu le "Boom" lointain qui a détruit son terrain de jeu préféré au barrage, où se trouvait également la vanne.
Que s'est-il passé ensuite ?
L'inondation a emporté toutes les précieuses cultures. La banque a pris la ferme du père du garçon. Son père n'a pas pu payer pour une bonne éducation. Alors le garçon a rejoint l'armée pour obtenir une éducation supérieure. Là, il a tout appris sur la physique des explosifs et essaie maintenant d'inventer un barrage résistant aux explosions.
Qu'est-ce que cette histoire a à voir avec ceci ici ?
- Les agriculteurs de récoltes sont les autres réponses.
- Le petit garçon est cette réponse ici.
- Le barrage est le mode sommeil sans échec d'Ubuntu.
- La vanne est le bon réglage de l'interface.
- L'eau est le processus de démarrage.
- Les cultures sont votre système d'exploitation Ubuntu.
- Et le canal rempli est à quoi le processus de démarrage devrait ressembler.
Le réglage de l'interface, qui vit dans /etc/network/interfaces
, est soufflé avec le sommeil en mode sans échec supprimé, et même si quelqu'un voit la vanne fermée (auto
), personne n'a remarqué qu'elle pouvait aussi être ouverte !