Запуск задания на eth0

Я использую новую установку Arch Linux, и каждый раз, когда я загружаю свою систему, мне приходится ждать 90 секунд, так как для моих сетевых интерфейсов выполняется начальная задача.

Я установил Arch вчера, и каждый раз, когда я выполняю ip a, я вижу, что Ethernet интерфейс находится в состоянии DOWN. Я использовал проводное USB-тетеринг для завершения установки. Я просто хочу убрать эту начальную задачу при запуске. Я видел решение где-то в сообществе Arch, что мне нужно отключить мой интерфейс с помощью:

# systemctl disable dhcpcd@interface_name

Я еще этого не сделал. Мой вопрос: если я отключу этот интерфейс, вызовет ли это какие-либо проблемы в будущем? Сейчас я не использую LAN-подключения. Вызовет ли это проблемы, если в будущем я захочу использовать LAN или какое-либо Ethernet-соединение?

Вывод 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.369s (прошивка) + 1.785s (загрузчик) + 5.214s (ядро) + 1мин 33.882s (пользовательское пространство) = 1мин 46.252s
графический.target достигнут после 1мин 33.882s в пользовательском пространстве

/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
Запуск завершился за 5.369s (прошивка) + 1.785s (загрузчик) + 5.214s (ядро) + 1мин 33.882s (пользовательское пространство) = 1мин 46.252s
графический.target был достигнут после 1мин 33.882s в пользовательском пространстве

Вывод systemd-analyze critical-analyze :

[siddharth@brightprogrammer ~]$ systemd-analyze critical-chain
Время после активации или запуска юнита печатается после символа "@".

графический.target @1мин 33.882s
└─gdm.service @1мин 33.615s +265ms
  └─systemd-user-sessions.service @1мин 33.503s +110ms
    └─network.target @1мин 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
   Загружено: загружено (/usr/lib/systemd/system/[email protected]; включено; поставщик по умолчанию>
   Активно: неактивно (не активно)

Mar 05 09:42:42 brightprogrammer systemd[1]: Не удалось выполнить зависимость для dhcpcd на eth0.
Mar 05 09:42:42 brightprogrammer systemd[1]: [email protected]: Задача [email protected]/start не выполнена с результатом 'зависимость'.

[siddharth@brightprogrammer ~]$ sudo systemctl status [email protected]
● [email protected] - dhcpcd на enp1s0f1
   Загружено: загружено (/usr/lib/systemd/system/[email protected]; отключено; поставщик по умолчанию>
   Активно: неактивно (не активно)

Я недавно отключил enp1s0f1. Это может быть причиной его отключения.

Я также могу предоставить вывод journalctl -xe, но он очень большой! Также я подозреваю, что dhcpcd каким-то образом запутался между eth0 и enp1s0f1

Я бы сказал, что скорее всего проблема, которую вы наблюдаете, связана с [email protected], который настроен в вашей системе. Поэтому моя рекомендация – отключить его, надеюсь, этого будет достаточно, чтобы избавиться от тайм-аута во время загрузки:

$ sudo systemctl disable dhcpcd@eth0

Я просмотрю доказательства, подтверждающие это утверждение. Здесь можно сделать еще несколько шагов по устранению неполадок, я предложу еще несколько шагов (в случае, если вы захотите продолжить исследование или устранить подобные проблемы в будущем).

Основное доказательство проблемы – это сообщение в выводе systemctl status dhcpcd@eth0, которое говорит:

Mar 05 09:42:42 brightprogrammer systemd[1]: [email protected]: Задача [email protected]/start не выполнена с результатом 'зависимость'.

Неудача с результатом “зависимость” означает, что в данном случае он ожидал чего-то другого, что не сработало. Эта служба будет зависеть от eth0.device, и это устройство не появится, поэтому это вероятный источник тайм-аута. Вы можете взглянуть на systemctl status eth0.device, чтобы увидеть, не появится ли что-то еще, возможно, это произойдет (но также возможно, что нет).

Как вы упомянули в своем вопросе, вероятно, возникла путаница между eth0 и фактическим именем устройства enp1s0f1 в вашей системе. systemd (а точнее, udevd) переименует сетевые интерфейсы, чтобы дать им согласованное имя, и это обычно происходит очень рано при загрузке (иногда даже до загрузки systemd), так что systemd на самом деле не увидит имя eth0 больше.

Если вы захотите включить DHCP на этом интерфейсе в будущем, включите dhcpcd@enp1s0f1 вместо этого.

Вывод systemd-analyze critical-chain поддерживает гипотезу о тайм-ауте на службе dhcpcd@eth0, что вы можете увидеть из этих двух шагов:

└─network.target @1мин 33.501s    
  └─wpa_supplicant.service @15.761s +638ms 

Времена после @ – это часы, отмеченные сразу после загрузки. Служба wpa_supplicant заработала через 13 секунд после запуска systemd, но network.target был достигнут только через 1м33с (примерно те 90 секунд, о которых вы говорите).

Вы, вероятно, увидели бы dhcpcd@eth0 здесь более явно, но юнит на самом деле вошел в состояние “загружено”, “не активно”, а не “неудачно”, поэтому, вероятно, именно поэтому он не был ярко выделен здесь (и в systemd-analyze blame), что помогло бы указать, что это виновник.

Наконец, один шаг, который обычно имеет большой успех при устранении проблем с загрузкой systemd, – это начать с просмотра голого вывода systemctl status, который сообщит вам, находится ли система в “деградированном” состоянии, что указывает на то, что что-то потерпело неудачу во время загрузки. Вы хотите убедиться, что статус системы будет “работает”, поэтому исследование этих неудач обычно выявляет проблемы, такие как тайм-ауты и т. д.

Вы можете продолжить расследование с этого момента, взглянув на вывод systemctl, который перечислит все активные юниты и их статус, если вы видите проблемы, исследуйте дальше, изучая конкретные юниты (с помощью systemctl status <unit> или journalctl -u <unit>). Команда systemctl --state=failed также полезна для отображения только неудачных юнитов.

Наконец, проверка журнала действительно полезна для установления корреляций. Команда journalctl -b показывает журнал с момента загрузки системы, так что это здорово для изучения проблем во время загрузки. Как уже упоминалось ранее, journalctl -u <unit> полезен для изучения логов для одного юнита.

Надеюсь, эти советы будут полезны вам для более глубокого понимания того, что происходит в вашей системе. Также надеюсь, что отключение dhcpcd@eth0 будет достаточно для решения задержки загрузки, которую вы испытываете.

Я наконец решил эту проблему, повторно включив юнит systemd для указанного профиля (eth0).

netctl reenable eth0

Теперь задержка в 90 секунд устранена после перезагрузки.

Проблема в том, что когда у вас еще не настроена сеть (типично после свежей установки), система пытается запустить все сетевые процессы. До тех пор, пока конфигурация сети не будет должным образом установлена, просто отключите зависимость сервисов сессий пользователей systemd и сетевых демонов.

Из: /usr/lib/systemd/system/systemd-user-sessions.service

Секция: [Unit]

Строка: After=….

уберите network.target, затем выполните systemctl daemon-reload

Проблема в моем случае заключалась в том, что я сказал systemd, что я всегда хотел, чтобы конкретный сервис запускался, даже если интерфейс не был доступен, поэтому он ждал 90 секунд, пока интерфейс не станет доступен, потому что я сказал ему, что сервис всегда должен быть запущен:

systemctl enable wpa_supplicant@eth0   # Всегда запускать, даже если eth0 отсутствует

Решением была обратная логика: вместо того, чтобы говорить, что я всегда хочу, чтобы этот сервис работал, даже если сетевой интерфейс отсутствует, мне нужно было отметить сетевой интерфейс как требующий сервис systemd для запуска. Таким образом, если сетевой интерфейс не существовал, он никогда не пытался бы запустить сервис, и задержки загрузки не будет.

В моем случае это был сервис wpa_supplicant, который я использовал. Сначала мне нужно было отключить его с помощью systemctl disable wpa_supplicant@eth0, чтобы предотвратить его запуск каждый раз, даже если eth0 не существовал.

Затем я создал некоторые новые правила udev в /etc/udev/rules.d/50-network.rules, которые содержали эту строку:

ACTION=="move", SUBSYSTEM=="net", KERNEL=="eth0", ENV{SYSTEMD_WANTS}+="[email protected]"

Обратите внимание, что ACTION кажется add, если вы используете нативное имя интерфейса ядра (например, eth0), но move, если интерфейс переименовывается (например, в что-то вроде enp0s1f2 или wlp0s1).

После перезагрузки у меня больше не было задержек загрузки, и сервис запускается только если сетевой интерфейс присутствует.