ip link set up/down: как скрипты вызываются?
Многие файловые системы имеют динамически размещаемую таблицу inode (или ее моральный эквивалент)(XFS, BTRFS, ZFS, VxFS...)
Исходная Unix UFS, хотя и имела индексы, которые были зафиксированы во время создания файловой системы, и файловые системы, производные от нее (Linux EXT, Solaris UFS )часто продолжали схему. Он надежный и простой в реализации. Так много вариантов использования хорошо подходят, что разработка новой файловой системы только для того, чтобы избежать этой одной проблемы, нелегко оправдать.
Вызов ip link set <iface> up, как вы описываете, просто выполняет минимальную связь с ядром черезrtnetlink API (, который касается не только маршрутов, но также ссылок, адресов и т. д. Здесь это будетRTM_NEWLINK)для администрирования интерфейса. Более старый инструмент ifconfigзапрашивает то же самое у ядра, используя устаревший (для сети )ioctl API (, здесь это будетSIOCGIFFLAGS).
Эти команды являются командами низкого уровня, которые делают только то, что было запрошено, и ничего больше.
ifupявляется частью (в Debian )пакетаifupdown(или альтернативного набораifupdown2)и имеет разные реализации в разных дистрибутивах Linux. Это просто набор скриптов, вероятно, вызывающих ip link set...самих себя,и, возможно, некоторые из них также будут напрямую использовать другие доступные инструменты (, такие как NetworkManager). Так что ставить их на один уровень совершенно нельзя:ip link set... upсовсем не ifup....
Теперь, как другие сетевые инструменты, такие как NetworkManager , взаимодействуют и узнают, что произошло? Потому что они просят ядро через rtnetlink получать уведомления о некоторых интересующих их сетевых событиях. Реализация API netlink поддерживает многоадресную рассылку :, что означает, эффективно принимается несколькими заинтересованными сторонами (, принадлежащими пользовательскому пространству или ядру ), что упрощает реализацию событий.
Обычно, когда что-то (здесьip link set... up)отправляет сообщение ядру, ядро отвечает сообщением, которое рассылается заинтересованным сторонам :Команда ip linkполучает это сообщение обратно, но также и все ожидающие инструменты, которые теперь знают, что "интерфейс был только что активирован" (. Я не буду рассматривать различия между административным состоянием up и рабочим состоянием up ).
То же самое можно сделать в скрипте, используя цикл событий, управляемый выводом команды ip monitor, которая ожидает сетевых событий от ядра. Конечно, предпочтительнее действительно анализируемый вывод, к сожалению, в то время как многие другие команды iproute2 sub -поддерживают вывод JSON (с использованием -json), что не относится к ip monitor.
Вот базовый пример оболочки, основанный на ip monitor linkдля отображения рабочего статуса интерфейса всякий раз, когда в этот интерфейс вносятся изменения (, даже если это не связано с его рабочим статусом. a базовый пример ). Поскольку он анализирует ненадежные выходные данные, ожидайте, что в некоторых случаях он не будет работать :
#!/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
То же самое возможно с адресами, маршрутами и т.д.Вот как такие инструменты, как NetworkManager , реагируют на команду ip link set <iface> up.