web-dev-qa-db-ja.com

eth0の開始ジョブが実行されています

私はArch Linuxの新規インストールを使用しており、システムを起動するときは常に、ネットワークインターフェースに対して実行中の開始ジョブがあるため、90秒待つ必要があります。

私は昨日Archをインストールしましたが、ip aを実行するたびに、イーサネットインターフェイスが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がeth0と私のenp1s0f1の間でなんらかの混乱を招いているのではないかと思います。

arch-linuxsystemddevicesethernetdhcpcd
2
Siddharth Mishra

あなたが見ている問題は、システムで設定されている[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と実際のデバイス名enp1s0f1は混同している可能性があります。 systemd（より具体的にはudevd）は、ネットワークインターフェースの名前を変更して一貫した名前を付けます。これは通常、起動時の非常に早い段階で（場合によってはsystemdが起動する前でも）、systemdは実際にはeth0の名前を認識しません。

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

systemd-analyze critical-chainの出力は、そのdhcpcd@eth0サービスのタイムアウトの仮説をサポートしています。これは、次の2つのステップから確認できます。

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

@の後の時間は、ブート直後のクロック時間です。 systemdが起動してから13秒後にwpa_supplicantサービスが起動しましたが、network.targetに到達したのは1分33秒（およそ90秒ほど）でした。

おそらくここでdhcpcd@eth0をより明確に見ていたはずですが、ユニットは実際に「失敗」ではなく「ロード済み」/「非アクティブ」状態になりました。そのため、ここに目立つようにリストされていません（そしてsystemd-analyze blame）、それが原因としてそれを指摘するのに役立ちました。

最後に、systemdブートの問題のトラブルシューティングを行う際に通常優れたスタートとなるステップの1つは、システムが「劣化」状態にあるかどうかを示す、裸のsystemctl status出力を調べることです。これは、ブート中に何かが失敗したことを示します。システムステータスが「実行中」であることを確認したいので、これらの障害を調査すると、通常、タイムアウトなどの問題が明らかになります。

systemctlの出力を見ると、その時点から調査を進めることができます。これにより、すべてのアクティブなユニットとそのステータスがリストされます。そこで問題が発生した場合は、特定のユニットを調査して（systemctl status <unit>またはjournalctl -u <unit>。）コマンドsystemctl --state=failedは、故障したユニットのみを表示する場合にも役立ちます。

最後に、ジャーナルをチェックすることは、相関を作成するために本当に良いです。コマンドjournalctl -bは、システムが起動してからのジャーナルを表示するので、起動中に問題を調べるのに最適です。前述したように、journalctl -u <unit>は単一のユニットのログを調査するのに役立ちます。

うまくいけば、これらのヒントは、システムを深く掘り下げ、システムで何が起こっているのかを理解するのに役立ちます。また、そのdhcpcd@eth0を無効にするだけで、起動時の遅延を解決できることを期待しています。

3
filbranden

指定したプロファイル（eth0）のsystemdユニットを再度有効にすることで、この問題を最終的に解決しました。

netctl reenable eth0

これで、再起動後に90秒の起動がクリアされました。

0
cifranix

問題は、まだネットワークを構成していない場合（通常、新規インストール後）ですが、システムがネットワーク全体を起動しようとしています。 net configが適切に確立されるまで、systemdユーザーセッションとネットワークデーモンの依存関係を無効にします。

From：/usr/lib/systemd/system/systemd-user-sessions.service

セクション：[ユニット]

行：後= ....

remove network.targetその後、systemctl daemon-reloadを実行します

0
Grzegorz Olbryś