CentOS 7を初めて使用し、CentOS 7で静的IPを構成しているので、/etc/sysconfig/network-scipts/ifcfg-eth0
ファイルを次のように編集しました。
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
しかし、コマンドを発行すると
systemctl restart network
エラーが出ます
failed to start LSB :/Bring Up down Networking
ip route show
は何も出力しません。
同じ既存のエラーでNetworkManagerを停止するソリューションを適用しました。
動的DHCPを構成して動的IPアドレスを取得できますが、静的IPアドレスは取得できません。
可能な解決策は何ですか?
BOOTPROTOを静的に変更し、DNS構成を/etc/resolv.confファイルに移動する必要があります。次に例を示します。
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
実行tee /etc/modprobe.d/*blacklist*.conf <- "blacklist ideapad_laptop"
その後、再起動します。これでWi-Fiのブロックが解除されます。
私は私のケースへの答えを探してここに来たので、共有します。多分それは他の誰かを助けるでしょう。これを指摘してくれたcPanelのスタッフに感謝します
報告された問題については、「3.10.0-862」より前のカーネルバージョンを実行しているCloudLInuxサーバーがCloudlinux 7.7にアップデートされ、「iproute」パッケージがアップデートされることが確認されています。
「iproute」パッケージは、新しいカーネルを枯渇させるか、最初にサーバーへの更新から除外する必要があります。
この情報は報告されています。あなたはそれについてここにいくつかの詳細情報を見つけることができます:
https://www.cloudlinux.com/cloudlinux-os-blog/entry/cloudlinux-os-7-7-released
私の場合
journalctl -xe
同じUUIDを使用して重複するインターフェース設定eth0&eno1があったことを示します:
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 ]
未使用のインターフェイスifcfgファイルを削除すると、問題が解決しました。
私のローミングラップトップの適切なautossh機能を脱線させるこの問題に直面したとき、私は根本的な原因を理解するためにMageiaOSコードを分解することにしました。私はNetworkManagerを持っていなかったので、それが障害ではないことは確かでした。
見つかった問題は、SysVとネットワークサービスを管理するsystemdの方法との間の最終的なライブロックのようなものとして説明できます。潜在的に、多くの条件がそれをトリガーする可能性があります(NetworkManagerは例の1つです)。
SysV/systemdのバランスの各部分に2つの重要なブロッカーがあり、ループで互いにトリガーし始める可能性があります。 SysV側では、init.d/networkスクリプトは最終的に「ifup $ device boot」を呼び出します。これは、「boot」パラメーターの応答として、プラグ可能なifacesのifplugdデーモンを開始します。 '-I'スイッチ(エラーを無視するために使用)にもかかわらず、メモリ内で自身を検出すると、終了コード4で失敗するこのデーモンの問題。ネットワークスクリプトからこのデーモンをシャットダウンする唯一の適切な方法は、「ifdown $ device boot」コマンドを発行することです。これは、「service」または「systemctl」コマンドによってネットワークサービスを停止したときに実行されるはずです。
この質問の興味深い部分:ネットワークサービスが開始する前にifplugdがすでにメモリにあるのはなぜですか?まあ、私の場合、vbox ifaceが誤って設定される前にWiFi ifaceが起動されましたが、後者はinitscript全体を失敗させていました。したがって、ネットワークは起動時に開始されましたが、サービスのステータスは失敗として記録されました。しかし、ネットワークサービスを停止し、その結果ifdown/bootコマンドからifplugdを強制終了するのを妨げているのは何ですか答えは、ユニットファイル内のExecStopディレクティブを処理する独創的な方法でsystemdです(ネットワークサービス用にオンザフライで自動生成されます)。基本的に、「systemctl stop」コマンドは、サービスが開始されていないと判断した場合、ExecStopディレクティブを無視します。まあ、もちろんそうではありません...以前に予期しないifplugdインスタンスにつまずくのに失敗した場合!したがって、サービスを停止する方法はないため、ifplugdを削除する方法はないため、サービスを(再)開始する方法などはありません。
結論。ネットワークスクリプトとsystemdアプローチの間の互換性のバランスは非常に脆弱であるため、この種のトラブルの単一のレシピはありません。そのため、多くの予期しない要因が干渉し始める可能性があります。このシナリオをトラブルシューティングするには、いくつかのステータスが役立つ場合があります。
そしてもちろん、「bash -x」とデバッグ「echo Bump」命令。 :-)
長期的な解決策は、ifplugdがこのシナリオで「-I」スイッチを尊重するように修正することです。中期的な解決策は、ifplugdの戻りコードを無視するように/ etc/sysconfig/network-scripts/ifup-ethを修正することです。短期的な解決策は最もトリッキーなようです。これは、このライブロックをトリガーするすべての可能な構成要素を削除するだけです。しかし、これはシステムの自動更新を許容する唯一のものです...