Impossible de démarrer LSB: Bring Up Down Networking
Je suis nouveau sur CentOS 7 et je configure une adresse IP statique sur CentOS 7, j'ai donc modifié le fichier /etc/sysconfig/network-scipts/ifcfg-eth0 comme suit:
TYPE=Ethernet
BOOTPROTO=none
Device=eth0
ONBBOOT=yes
IPADDR=192.168.4.196
NETMASK=255.255.255.0
GATEWAY=192.168.88.254
DNS1=8.8.8.8
USERCTL=no
Mais quand j'émets la commande
systemctl restart network
Je reçois l'erreur
failed to start LSB :/Bring Up down Networking
ip route show ne me donne aucune sortie.
J'ai appliqué la solution qui arrête NetworkManager avec la même erreur existante.
Je peux configurer un DHCP dynamique et obtenir une adresse IP dynamique mais pas statique.
Quelles peuvent être les solutions possibles?
C'est à cause d'un problème d'interface
La solution qui a fonctionné pour moi était:
Vérifiez l'interface disponible
cp ifcfg-eno16780032 ifcfg-ens192
vi ifcfg-ens192 et changez [~ # ~] nom [~ # ~] et Périphérique champ à ens192
systemctl disable NetworkManager
systemctl status NetworkManager -> inactive
systemctl stop network
systemctl start network
Après cette vérification ip a obtenir les détails de l'IP et pouvoir envoyer une requête ping à cette IP.
Vous devez changer BOOTPROTO en statique et déplacer votre configuration DNS vers votre fichier /etc/resolv.conf, par exemple:
TYPE=Ethernet
BOOTPROTO=static
PHYSDEV=eth0
ONBBOOT=yes
IPADDR=192.168.4.196
NETMASK=255.255.255.0
GATEWAY=192.168.88.254
USERCTL=no
Exécutez tee /etc/modprobe.d/*blacklist*.conf <- "blacklist ideapad_laptop"
Redémarrez ensuite. Cela devrait débloquer votre Wi-Fi.
Je suis venu ici à la recherche d'une réponse à mon cas, je vais donc partager, peut-être que cela aidera quelqu'un d'autre. Je remercie le personnel de cPanel de me l'avoir signalé
En ce qui concerne les problèmes signalés, nous avons vu les serveurs CloudLInux exécuter une version de noyau inférieure à "3.10.0-862" et une mise à jour vers Cloudlinux 7.7, ils obtiendront une mise à jour du package 'iproute'.
Le paquet 'iproute' doit flétrir un noyau plus récent ou être exclu de la mise à jour sur le serveur initialement.
Cette information a été rapportée. Vous pouvez trouver plus d'informations à ce sujet ici:
https://www.cloudlinux.com/cloudlinux-os-blog/entry/cloudlinux-os-7-7-released
Dans mon cas
journalctl -xe
Indique qu'il y avait une configuration d'interface en double eth0 et eno1 utilisant le même UUID:
Nov 06 09:35:41 4200-150-137 /etc/sysconfig/network-scripts/ifup-eth[27549]: Device eno1 does not seem to be present, del
Nov 06 09:35:41 4200-150-137 network[27401]: [FAILED]
Nov 06 09:35:41 4200-150-137 network[27401]: Bringing up interface eth0: [ OK ]
la suppression du fichier ifcfg de l'interface inutilisée a résolu le problème pour moi.
Face à ce problème qui a fait dérailler la fonctionnalité d'autossh appropriée sur mon ordinateur portable en itinérance, j'ai décidé de déchirer le code MageiaOS pour comprendre la cause première. Je n'avais pas NetworkManager, je savais donc que ce n'était pas l'obstacle.
Le problème trouvé pourrait être décrit comme une sorte de verrouillage en direct éventuel entre SysV et les méthodes de gestion des services réseau par le système. Potentiellement, de nombreuses conditions pourraient le déclencher (NetworkManager en est un exemple), dans mon cas, il s'agissait d'ifaces vboxnet mal configurées de VMWare.
Il y a deux bloqueurs critiques dans chaque partie de l'équilibre SysV/systemd qui pourraient commencer à se déclencher dans la boucle. Côté SysV, le script init.d/network appelle finalement "ifup $ device boot", qui en réponse au paramètre 'boot' démarre le démon ifplugd pour les ifaces enfichables. Le problème avec ce démon est que, malgré le commutateur '-I' (utilisé pour ignorer les erreurs), il échoue toujours avec le code de sortie 4 lors de sa détection en mémoire. La seule façon appropriée d'arrêter ce démon à partir d'un script réseau est d'émettre la commande "ifdown $ device boot", qui est censée être exécutée à l'arrêt du service réseau par les commandes 'service' ou 'systemctl'.
La partie intéressante de cette question: pourquoi ifplugd est déjà en mémoire avant le démarrage du service réseau? Eh bien, dans mon cas, l'iface WiFi a été déclenché avant une vbox iface mal configurée, mais cette dernière a entraîné l'échec de l'intégralité du script. Ainsi, le réseau a été démarré au démarrage mais l'état du service a été enregistré comme défaillant. Mais qu'est-ce qui nous empêche simplement d'arrêter le service réseau et, par conséquent, de tuer ifplugd de la commande ifdown/boot? La réponse est: systemd dans ses manières ingénieuses de gérer la directive ExecStop dans le fichier d'unité (qui est généré automatiquement à la volée pour le service réseau). Fondamentalement, la commande "systemctl stop" ignore simplement la directive ExecStop si elle estime que le service n'est pas démarré. Eh bien, bien sûr, ce n'est pas parce que ... en cas d'échec antérieur, on tombe sur une instance ifplugd inattendue! Donc, aucun moyen d'arrêter le service, donc aucun moyen de se débarrasser d'ifplugd, donc aucun moyen de (re) démarrer le service et ainsi de suite.
Conclusion. Il n'y a pas de recette unique pour ce genre de problème car l'équilibre de compatibilité entre le script réseau et l'approche systemd est très fragile, de nombreux facteurs inattendus peuvent donc commencer à interférer. Pour résoudre ce scénario, plusieurs statuts peuvent être utiles:
- service réseau: réseau d'état systemctl
- service ifplugd: ps ax | grep ifplugd
- état de la liaison réseau: ifconfig/iwconfig
- unité générée automatiquement: cat /var/run/systemd/generator.late/network.service
- d'autres endroits exécutant ifup indépendamment: grep -rs ifup/etc
et bien sûr, l'instruction "bash -x" et le débogage "echo Bump". :-)
La solution à long terme consiste à corriger ifplugd pour respecter le commutateur "-I" dans ce scénario. La solution à moyen terme consiste à corriger/etc/sysconfig/network-scripts/ifup-eth pour ignorer le code retour ifplugd. La solution à court terme semble être la plus délicate, qui consiste simplement à supprimer tous les facteurs de configuration possibles déclenchant ce verrouillage en direct. Mais c'est le seul qui tolère les mises à jour automatiques du système ...