eth0에 대한 시작 작업 실행 중

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사이에 약간의 혼란이 있다고 생각합니다.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대신 활성화하십시오.

의 출력은 다음 두 단계에서 볼 수 있는 systemd-analyze critical-chain서비스 시간 초과라는 가설을 뒷받침합니다 .dhcpcd@eth0

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

그 이후의 시간 @은 시작 이후의 시계 시간입니다. wpa_supplicantsystemd가 시작된 지 13초 후에 서비스가 시작되었지만 1 network.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를 실행하십시오.

관련 정보