В зависимости от дистрибутива, вызов ip link set <iface> up(или down; также ifup / ifdown) будет просматривать различные файлы конфигурации (я думаю, /etc/network/interfaces в Debian, в Gentoo есть /etc/conf.d/net...), и вносить изменения (например, взаимодействовать с DHCP и т. д.)
Насколько я понял из strace, ipкоманда напрямую общается с ядром (так ли это?). Но затем, в конце концов, кто-то запускает эти скрипты оболочки / читает конфигурацию. Какой механизм стоит за этим? Система инициализации прослушивает какой-то интерфейс ядра на предмет изменений состояния up / down и запускает эти скрипты? Или это что-то другое?
решение1
Вызов ip link set <iface> up, как вы описываете, — это просто минимальное взаимодействие с ядром черезrtnetссылкаAPI(что касается не только маршрутов, но и ссылок, адресов и т. д. Здесь это будет RTM_NEWLINK) для административного поднятия интерфейса. Более старый ifconfigинструмент запрашивает то же самое у ядра, используя устаревший (для сети) API ioctl (здесь это будет SIOCGIFFLAGS).
Это команды низкого уровня, которые выполняют только то, что было запрошено, и ничего более.
ifupявляется частью (в Debian)есливверхвниз(или альтернативный вариант)еслиupdown2) suite, и имеет различные реализации в различных дистрибутивах Linux. Это просто набор скриптов, вероятно, вызывающих ip link set ...самих себя, и, возможно, некоторые из них также будут напрямую использовать другие доступные инструменты (например,Сетевой менеджер). Так что ставить их на один уровень категорически нельзя: ip link set ... upэто совсем не так ifup ....
Теперь, как другие сетевые инструменты, такие какСетевой менеджервзаимодействовать и знать, что произошло? Потому что они спрашивают ядро, черезrtnetссылка, чтобы получать уведомления о некоторых сетевых событиях, которые им интересны.netlinkРеализация API поддерживает многоадресную передачу: это означает, что одно сообщение может быть эффективно получено несколькими заинтересованными сторонами (принадлежащими к пользовательскому пространству или ядру), что упрощает реализацию событий.
Обычно, когда что-то (здесь ip link set ... up) отправляет сообщение ядру, ядро отвечает сообщением, которое рассылается заинтересованным сторонам: Команда ip linkполучает это сообщение обратно, но также и все ожидающие инструменты, которые теперь знают, что «интерфейс только что был поднят» (я оставлю в стороне различия между административным состоянием «включено» и рабочим состоянием «включено»).
То же самое можно сделать в скрипте, используя цикл событий, управляемый выводом команды.ip monitorкоторый ждет сетевых событий от ядра. Конечно, действительно разборчивый вывод был бы предпочтительнее, к сожалению, в то время как многие другиеiproute2Подкоманды поддерживают вывод JSON (с использованием -json), что не относится к ip monitor.
Вотбазовыйпример оболочки, основанный на ip monitor linkотображении статуса оператора интерфейса всякий раз, когда вносится изменение в этот интерфейс (даже если это не связано с его статусом оператора... этобазовыйпример). Поскольку он анализирует ненадежные выходные данные, ожидайте, что в некоторых случаях он даст сбой:
#!/bin/sh
ip -o monitor link | while read -r index interface status remaining; do
iface=$(printf '%s\n' "$interface" | sed -E 's/(@.*)?:$//')
operstate=$(printf '%s\n' "$remaining" | grep -Eo ' state [^ ]+' | sed 's/^ state //')
printf '%s %s\n' "$iface" "$operstate"
done
Пока выполняется скрипт, указанный выше, попробуйте выполнить следующие команды в другом месте:
# ip link add test1 type veth peer name test2
# ip link set test1 up
# ip link set test2 up
# ip link delete test1 # script doesn't handle correctly lines starting with Deleted
То же самое возможно с адресами, маршрутами и т. д. Вот как работают такие инструменты, какСетевой менеджерреагируют на команду ip link set <iface> up.