☰

eth0の起動ジョブの実行中

tag-icon • tag-icon arch-linux systemd devices ethernet dhcpcd
eth0の起動ジョブの実行中

私はArch Linuxを新しくインストールして使用しており、システムを起動するたびにネットワークインターフェイスが起動操作を実行している間90秒待つ必要があります。

昨日はArchをインストールしましたが、インストールするたびにip aEthernetインターフェイスがDOWN適切な状態であることを確認しました。フルインストールに有線USBテザーを使用しました。起動時に起動ジョブプロセスを削除したいです。 Archコミュニティのどこかで、次のようにインターフェイスを無効にする必要があるソリューションを見ました。

# systemctl disable dhcpcd@interface_name

私はまだそのようなことをしていません。私の質問は、インターフェイスを無効にすると後で問題が発生しますか？現在LAN接続を使用していません。後でLANまたはイーサネット接続の種類を使用したい場合は、この問題が発生しますか？

出力uname -a：

[siddharth@brightprogrammer ~]$ uname -a
Linux brightprogrammer 4.19.26-1-lts #1 SMP Wed Feb 27 16:06:52 CET 2019 x86_64 GNU/Linux

出力ip a：

[siddharth@brightprogrammer ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp1s0f1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether 80:fa:5b:5b:9e:47 brd ff:ff:ff:ff:ff:ff
3: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 94:b8:6d:c9:57:89 brd ff:ff:ff:ff:ff:ff
    inet 192.168.43.201/24 brd 192.168.43.255 scope global dynamic noprefixroute wlp2s0
       valid_lft 2153sec preferred_lft 2153sec
    inet6 2405:205:a061:4977:348c:2fe2:102:47ac/64 scope global noprefixroute 
       valid_lft forever preferred_lft forever
    inet6 fe80::614a:460c:ff14:9caa/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

出力find /etc/systemd：

[siddharth@brightprogrammer ~]$ find /etc/systemd
/etc/systemd
/etc/systemd/journald.conf
/etc/systemd/coredump.conf
/etc/systemd/sleep.conf[siddharth@brightprogrammer ~]$ systemd-analyze

起動完了時間は、5.369秒（ファームウェア）+ 1.785秒（ローダー）+ 5.214秒（カーネル）+ 1分33.882秒（ユーザースペース）= 1分46.252秒（グラフィック）です。ユーザースペースで1分33.882秒後に目標に達しました。

/etc/systemd/journal-remote.conf
/etc/systemd/system.conf
/etc/systemd/timesyncd.conf
/etc/systemd/journal-upload.conf
/etc/systemd/networkd.conf
/etc/systemd/system
/etc/systemd/system/getty.target.wants
/etc/systemd/system/getty.target.wants/[email protected]
/etc/systemd/system/dbus-org.freedesktop.nm-dispatcher.service
/etc/systemd/system/bluetooth.target.wants
/etc/systemd/system/bluetooth.target.wants/bluetooth.service
/etc/systemd/system/multi-user.target.wants
/etc/systemd/system/multi-user.target.wants/NetworkManager.service
/etc/systemd/system/multi-user.target.wants/[email protected]
/etc/systemd/system/multi-user.target.wants/wicd.service
/etc/systemd/system/multi-user.target.wants/[email protected]
/etc/systemd/system/multi-user.target.wants/remote-fs.target
/etc/systemd/system/network-online.target.wants
/etc/systemd/system/network-online.target.wants/NetworkManager-wait-online.service
/etc/systemd/system/dbus-org.bluez.service
/etc/systemd/system/dbus-org.wicd.daemon.service
/etc/systemd/system/display-manager.service
/etc/systemd/system/dbus-org.freedesktop.NetworkManager.service
/etc/systemd/logind.conf
/etc/systemd/user
/etc/systemd/user/sockets.target.wants
/etc/systemd/user/sockets.target.wants/p11-kit-server.socket
/etc/systemd/user/sockets.target.wants/pipewire.socket
/etc/systemd/user/sockets.target.wants/gpg-agent.socket
/etc/systemd/user/sockets.target.wants/dirmngr.socket
/etc/systemd/user/sockets.target.wants/gpg-agent-extra.socket
/etc/systemd/user/sockets.target.wants/gpg-agent-browser.socket
/etc/systemd/user/sockets.target.wants/gpg-agent-ssh.socket
/etc/systemd/user/sockets.target.wants/pulseaudio.socket
/etc/systemd/user/default.target.wants
/etc/systemd/user/default.target.wants/xdg-user-dirs-update.service
/etc/systemd/user.conf
/etc/systemd/network
/etc/systemd/resolved.conf


出力systemd-analyze：

[siddharth@brightprogrammer ~]$ systemd-analyze
Startup finished in 5.369s (firmware) + 1.785s (loader) + 5.214s (kernel) + 1min 33.882s (userspace) = 1min 46.252s
graphical.target reached after 1min 33.882s in userspace


出力systemd-analyze critical-analyze：

[siddharth@brightprogrammer ~]$ systemd-analyze critical-chain
The time after the unit is active or started is printed after the "@" character.

graphical.target @1min 33.882s
└─gdm.service @1min 33.615s +265ms
  └─systemd-user-sessions.service @1min 33.503s +110ms
    └─network.target @1min 33.501s
      └─wpa_supplicant.service @15.761s +638ms
        └─basic.target @11.036s
          └─sockets.target @11.036s
            └─dbus.socket @11.036s
              └─sysinit.target @11.028s
                └─systemd-backlight@backlight:intel_backlight.service @14.008s >
                  └─system-systemd\x2dbacklight.slice @14.006s
                    └─system.slice @2.915s
                      └─-.slice @2.915s


出力systemd-analyze blame：

[siddharth@brightprogrammer ~]$ systemd-analyze blame
         11.692s [email protected]
         11.692s [email protected]
          6.472s lvm2-monitor.service
          4.616s wicd.service
          3.222s systemd-journal-flush.service
          3.188s NetworkManager.service
          2.719s bluetooth.service
          2.711s systemd-logind.service
          1.395s systemd-sysusers.service
          1.216s systemd-udevd.service
          1.213s ldconfig.service
           981ms udisks2.service
           971ms polkit.service
           649ms [email protected]
           638ms wpa_supplicant.service
           600ms systemd-modules-load.service
           526ms systemd-tmpfiles-setup.service
           501ms systemd-tmpfiles-setup-dev.service
           493ms upower.service
           487ms systemd-udev-trigger.service
           464ms systemd-journald.service
           371ms systemd-journal-catalog-update.service
           338ms systemd-sysctl.service
           268ms colord.service
           265ms gdm.service
           260ms kmod-static-nodes.service
           238ms dev-sda2.swap
           236ms accounts-daemon.service
           142ms systemd-random-seed.service
           135ms systemd-backlight@backlight:intel_backlight.service
           110ms systemd-user-sessions.service
            91ms [email protected]
            81ms systemd-update-utmp.service
            54ms systemd-remount-fs.service
            48ms sys-kernel-debug.mount
            35ms systemd-tmpfiles-clean.service
            28ms dev-hugepages.mount
            26ms [email protected]
            25ms sys-kernel-config.mount
            16ms [email protected]
            15ms dev-mqueue.mount
             9ms rtkit-daemon.service
             6ms systemd-update-done.service
             4ms systemd-rfkill.service
             3ms sys-fs-fuse-connections.mount
             2ms tmp.mount


そして出力：systemctl status [email protected]dhcpcd@enp1s0f1

[siddharth@brightprogrammer ~]$ sudo systemctl status [email protected]
● [email protected] - dhcpcd on eth0
   Loaded: loaded (/usr/lib/systemd/system/[email protected]; enabled; vendor pre>
   Active: inactive (dead)

Mar 05 09:42:42 brightprogrammer systemd[1]: Dependency failed for dhcpcd on eth0.
Mar 05 09:42:42 brightprogrammer systemd[1]: [email protected]: Job [email protected]/start failed with result 'dependency'.

[siddharth@brightprogrammer ~]$ sudo systemctl status [email protected]
● [email protected] - dhcpcd on enp1s0f1
   Loaded: loaded (/usr/lib/systemd/system/[email protected]; disabled; vendor pr>
   Active: inactive (dead)

最近 enp1s0f1 を無効にしました。これがおそらく無効になった理由です。

出力も提供できますが、journalctl -xe容量が非常に大きいです！私も私と私のdhcpcd間に少し混乱があると思います。eth0enp1s0f1

答え1

あなたが見ている問題は、[email protected]システムの構成に関連している可能性が最も高いです。だから私の提案はこれを無効にすることです。これは起動中のタイムアウトをなくすのに十分です。

$ sudo systemctl disable dhcpcd@eth0

私はこの主張を裏付ける証拠を詳しく見てみましょう。ここでより多くのトラブルシューティングが可能です。後でさらに詳しく学んだり、同様の問題を解決したい場合は、追加の手順を提案します。

問題の主な証拠は、systemctl status dhcpcd@eth0次の出力メッセージです。

Mar 05 09:42:42 brightprogrammer systemd[1]: [email protected]: Job [email protected]/start failed with result 'dependency'.

「依存関係」が失敗したという結果は、この場合失敗した他のものを待っていたという意味です。サービスはデバイスによって異なり、eth0.deviceデバイスが存在しないため、タイムアウトの原因になる可能性があります。systemctl status eth0.device他のものが表示されているかどうかを確認できます。おそらくそうです（しかしそうではないかもしれません）。

質問で述べたように、eth0実際のデバイス名とシステムの実際のデバイス名の間に混乱がある可能性があります。enp1s0f1systemd（より具体的にはudevd）は、ネットワークインタフェースの名前を変更して一貫した名前を与えます。これは通常ブート初期（時にはsystemdが起動する前）に発生するため、systemdは実際には名前を見ることができませんeth0。

後でこのインターフェイスでDHCPを有効にするには、dhcpcd@enp1s0f1代わりに有効にします。

の出力は、次の2つのステップで見られるsystemd-analyze critical-chainサービスタイムアウトという仮説を裏付けています。dhcpcd@eth0

└─network.target @1min 33.501s    
  └─wpa_supplicant.service @15.761s +638ms

それ以降の時間@は開始後の時計時間です。wpa_supplicantsystemdが開始して13秒後にサービスが開始されましたが、1network.target分33秒（おっしゃった通り約90秒）に達しました。

ここでより明確に見ることができますが、デバイスは実際には「失敗」ではなく「ロード済み」/「非アクティブ」状態になります。したがって、ここ（および内部）の列が強調表示されてdhcpcd@eth0いないのは、おそらくこのためです。systemd-analyze blameそれが犯人であることを指摘するのは役に立ちます。

最後に、システム起動の問題を解決するための最良のステップは、まず基本出力を調べることですsystemctl status。これにより、システムが起動プロセス中に問題が発生したことを示す「パフォーマンスの低下」状態であることがわかります。システムの状態が「実行中」であることを確認しようとしているため、これらのエラーを調べるとタイムアウトなどの問題が発生することがよくあります。

systemctlすべてのアクティブデバイスとそのステータスを一覧表示する出力を確認して、その時点から調べることができます。問題がある場合は、特定のデバイスを調査してさらに調査することができます（systemctl status <unit>または使用journalctl -u <unit>）。このコマンドをsystemctl --state=failed使用して、失敗したデバイス単位のみを表示することもできます。

最後に、ジャーナルを閲覧することは接続を作成するのに本当に役立ちます。このコマンドはjournalctl -bシステム起動後のログを表示するため、起動中の問題の確認に役立ちます。前述したように、journalctl -u <unit>単一ユニットのログを調べるのに便利です。

このヒントがシステムで何が起こっているのかをより深く掘り下げて理解するのに役立つことを願っています。また、この機能を無効にすると、dhcpcd@eth0現在発生している開始遅延の問題を解決するのに十分です。

答え2

最後に、指定されたプロファイル（eth0）に対してsystemdデバイスを再度有効にして問題を解決しました。

netctl reenable eth0

これで、再起動後90秒の起動時間がクリアされます。

答え3

問題は、まだネットワークを構成していませんが（通常は新しくインストールした後）、システムがネットワーク全体を起動しようとしている場合です。ネットワーク構成が正しく設定される前に、システムユーザーセッションとネットワークデーモンの依存関係を無効にするだけです。

送信者：/usr/lib/systemd/system/systemd-user-sessions.service

部品: [単位]

行：=...以降

ネットワーク。ターゲットを削除次に、systemctl daemon-reloadを実行します。

関連情報