Dependiendo de la distribución, al invocar ip link set <iface> up(o bajar; también ifup/ifdown) se examinarán varios archivos de configuración (/etc/network/interfaces en Debian, creo, Gentoo tiene /etc/conf.d/net...) y creará cambios (por ejemplo, interactuar con DHCP, etc.)
Por lo que he visto en strace, el ipcomando habla directamente con el kernel (¿es así?). Pero luego, eventualmente, alguien inicia esos scripts de shell/lee la configuración. ¿Cuál es el mecanismo detrás de que esto suceda? ¿El sistema de inicio está escuchando en alguna interfaz del kernel cambios de estado arriba/abajo y lanza estos scripts? o es algo diferente?
Respuesta1
Invocar ip link set <iface> upcomo usted describe es simplemente realizar una comunicación mínima con el kernel a través delenlace rtnetAPI(que no se trata solo de rutas, sino también de enlaces, direcciones, etc. Aquí sería RTM_NEWLINK) para abrir la interfaz administrativamente. La herramienta más antigua ifconfigle pregunta lo mismo al kernel usando la API ioctl obsoleta (para red) (aquí sería SIOCGIFFLAGS).
Estos comandos son comandos de bajo nivel que hacen sólo lo que se pidió y nada más.
ifupes parte (en Debian) de lasi arriba abajo(o el alternativosi arriba abajo2) suite y tiene diferentes implementaciones en diferentes distribuciones de Linux. Son sólo un conjunto de scripts, que probablemente se invocan ip link set ...a sí mismos, y tal vez algunos de ellos también utilicen directamente otras herramientas disponibles (comoGerente de Redes). Así que no puedes ponerlos al mismo nivel en absoluto: ip link set ... upno lo es en absoluto ifup ....
Ahora, ¿cómo les gustaría a otras herramientas de networking?Gerente de Redesinteractuar y saber qué pasó? Porque le están pidiendo al núcleo, a través deenlace rtnet, para recibir notificaciones sobre algunos eventos de la red que les interesen.enlace de redLa implementación de API admite multidifusión: eso significa que un solo mensaje puede ser recibido de manera eficiente por múltiples partes interesadas (pertenecientes al espacio de usuario o al kernel), lo que simplifica la implementación de eventos.
Normalmente, cuando algo (aquí ip link set ... up) envía un mensaje al kernel, el kernel responde con un mensaje que se transmite por multidifusión a las partes interesadas: el ip linkcomando recibe este mensaje de vuelta, pero también todas las herramientas en espera que ahora saben que "se acaba de abrir una interfaz". " (Dejaré de lado las diferencias entre estado administrativo arriba versus estado operativo arriba).
Es posible hacer lo mismo en un script usando un bucle de eventos impulsado por la salida del comando.ip monitorque está esperando eventos de red del kernel. Por supuesto, sería preferible un resultado realmente analizable, lamentablemente, mientras que muchos otrosiproute2Los subcomandos admiten una salida JSON (usando -json) que no es el caso de ip monitor.
Aquí está unbásicoEjemplo de shell basado en ip monitor linkmostrar el estado operativo de una interfaz cada vez que se realiza un cambio en esta interfaz (incluso si no está relacionado con su estado operativo... eso es unbásicoejemplo). Como está analizando resultados no confiables, espere que falle en algunos casos:
#!/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
Mientras se ejecuta el script anterior, pruebe estos comandos en otro lugar:
# 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
Lo mismo es posible con direcciones, rutas, etc. Así es como funcionan herramientas comoGerente de Redesestán reaccionando al comando ip link set <iface> up.