저는 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
답변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
실제 장치 이름과 시스템의 실제 장치 이름 사이에 혼동이 있을 수 있습니다. enp1s0f1
systemd(더 구체적으로 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_supplicant
systemd가 시작된 지 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를 실행하십시오.