¿Cómo recargar las reglas de udev sin reiniciar?

210

¿Cómo se deben volver a cargar las reglas de udev, para que pueda funcionar una recién creada?

Estoy ejecutando Arch Linux, y no tengo un udevstartcomando aquí.

También verificado /etc/rc.d, no hay servicio udev allí.

margarita
fuente
1
Tenga en cuenta que las versiones más recientes de udev han eliminado el soporte de inotify, por lo que la recarga de las reglas de cambio se necesita con más frecuencia en estos días.
Colin Guthrie
¿Qué es udev? ¿Es el gerente de /dev?
Sandburg
1
@Sandburg sí, maneja plug-n-play en sistemas Linux.
Aaron D. Marasco

Respuestas:

231
# udevadm control --reload-rules && udevadm trigger
Ignacio Vazquez-Abrams
fuente
44
¿Necesitas udevtriggerdespués?
Nils
38
@Nils En realidad, puede necesitar udevtrigger(o más bien udevadm triggeren la mayoría de las distribuciones) en su lugar (eso, o enchufar el dispositivo y volverlo a guardar). --reload-rulescasi siempre es inútil, ya que ocurre automáticamente.
Gilles
12
udevadm triggerhizo el truco en CentOS 6 para mí.
astrostl
3
udevtriggero udevadm triggerno funcionó para mí Encontré que algunos dispositivos funcionarán después de descargar y cargar el módulo para el mismo (suponiendo que sea un módulo cargable). Lo que descubrí es que uno no necesariamente tiene que reiniciar el sistema. Ejemplo para un dispositivo de red, hago rmmod ixgbe, rmmod tg3, rmmod e1000entonces modprobe ixgbe, modprobe tg3, modprobe e1000dependiendo del tipo de controlador de red.
enthusiasticgeek
1
Ninguna de las cosas mencionadas entre las respuestas me funcionó en Debian Jessie (8.0). Lo que funcionó se ip link set $oldname name $newnamemenciona aquí . En mi caso, necesitaba reemplazar un iface nombrado lanpor un iface en puente (para KVM) y, por lo tanto, el iface original, ahora subyacente, tenía que recuperar su antiguo nombre eth1. Entonces el truco fue: 1) derribar iface; 2) arreglar la configuración de red; 3) actualizar el archivo de reglas de nomenclatura udev; 4) cambie el nombre del iface usando ip link...; 5) sube el puente.
kostix
69

Udev utiliza el mecanismo de inotify para observar los cambios en el directorio de reglas, tanto en la biblioteca como en los árboles de configuración locales (generalmente ubicados en /lib/udev/rules.dy /etc/udev/rules.d). Por lo tanto, la mayoría de las veces no necesita hacer nada cuando cambia un archivo de reglas.

Solo necesita notificar explícitamente al demonio udev si está haciendo algo inusual, por ejemplo, si tiene una regla que incluye archivos en otro directorio. Luego puede usar la convención habitual para pedirle a los demonios que recarguen su configuración: envíe un SIGHUP ( pkill -HUP udevd). O puede utilizar el udevadmcomando: udevadm control --reload-rules.

Sin embargo, tenga en cuenta que las diferentes versiones de udev históricamente han tenido diferentes desencadenantes para recargar las reglas automáticamente. Entonces, si tiene dudas, llame udevadm control --reload-rules: de todos modos no hará ningún daño.

Las reglas de udev solo se aplican cuando se agrega un dispositivo. Si desea volver a aplicar las reglas a un dispositivo que ya está conectado, debe hacerlo explícitamente, llamando udevadm triggercon las opciones correctas para que coincidan con los dispositivos cuya configuración ha cambiado, por ejemplo udevadm trigger --attr-match=vendor='Yoyodyne' --attr-match=model='Frobnicator 300'.

Gilles
fuente
1
¿Systemd udev usa inotify para observar los cambios de reglas?
Craig McQueen
El inotifymecanismo no siempre detecta un cambio de un archivo de reglas udev. Por ejemplo, cuando uso cat > 10-name.rulespara cambiar el archivo de reglas pegando el contenido, tengo que volver a cargar las reglas manualmente udevadm. Probado en Raspbian Stretch.
Daniel K.
@DanielK. ¿Ha cambiado esto recientemente? IIRC Comprobé tanto un udev systemd como un udev no systemd cuando publiqué esta respuesta, y ambos usaron inotify, por --reload-ruleslo que solo era necesario en casos poco comunes.
Gilles
@Gilles: quizás mi ejemplo anterior (sobrescribir un archivo de reglas existente usando la redirección de shell) puede considerarse un "caso poco común". Cuando modifiqué este archivo a través de un editor, por ejemplo, vi, el inotifymecanismo funcionó.
Daniel K.
@DanielK. Ah, eso es bueno saberlo. No es un caso poco común: algunos editores guardarían el archivo reescribiéndolo (con Vim y Emacs, depende de cómo estén configurados). Es extraño que udev solo maneje uno de los casos; me parece un error, porque no puedo pensar en una razón para tratarlos de manera diferente.
Gilles
19

Estoy agregando esto porque algún día lo necesitaré ... otra vez.

A veces, obtienes una coincidencia incorrecta de números de dispositivo Ethernet y direcciones MAC. A veces esto es realmente importante, como cuando se ejecuta en una VM y cada dispositivo está asignado a una VLAN diferente.

  1. Baje las interfaces de red, luego
  2. modificar /etc/udev/rules.d/70-persistent-net.rules(o su equivalente)
  3. recargar con udevadm control --reload-rules
  4. reactivar con udevadm trigger --attr-match=subsystem=net
  5. Poner en marcha las interfaces de red.

Me sorprendió lo bien que funcionó.

Oteo
fuente
66
en Red Hat:service network stop && udevadm control --reload-rules; udevadm trigger --attr-match=subsystem=net; service network start
Alexander Torstling
1
En las pruebas de Debian, 'udevadm trigger --attr-match = subsystem = net' no funciona. Tuve que desconectar y conectar la tarjeta usb ethernet solo entonces udev activó una nueva regla.
Trismegistos
Trismegistos, estaría dispuesto a apostar que la desconexión / conexión es similar a quitar y volver a cargar el controlador de red, según la respuesta de Clayton Dukes.
Mike S
12

No estoy seguro de si esto se aplica, y esta es definitivamente una publicación anterior, pero surgió bastante alto en mi búsqueda web de información de udev, así que pensé que podría compartir algunos conocimientos.

Puede activar las reglas de udev manualmente para dispositivos específicos. Esto se aplica solo a las distribuciones relacionadas con redhat (centos fedora, etc., etc.)

Una vez que realice los cambios relevantes en su archivo de reglas ( /etc/udev/rules.d/whateveryoucalledyourrules), puede hacer eco changeen el evento del dispositivo.

echo change > /sys/block/devname/partname1/uevent

Esto forzará una lectura de la regla de udev SOLO para este dispositivo. Mucho mejor y más específico en mi opinión.

mbadmin
fuente
4

Para mí, la secuencia de comandos a continuación ha funcionado como se desea.

He realizado modificaciones /etc/udev/rules.d/70-persistent-net.rulespara cambiar el ethnúmero y volver a cargarlas sin reiniciar.

/etc/init.d/networking stop
/etc/init.d/udev stop
udevadm control --reload-rules
/etc/init.d/udev start
/etc/init.d/networking start

Siguiendo esto, se cargó con éxito en tiempo de ejecución sin reiniciar la máquina.

Cualquier sugerencia o recomendación sobre esto es bienvenida, ya que he descubierto esto por mi cuenta al leer las páginas de manual.

Aditya Malviya
fuente
2

Estoy agregando la respuesta correcta aquí porque me tomó un tiempo notarlo en el comentario de @enthusiasticgeek. Todo lo que necesita hacer (suponiendo que se encuentre en la consola del servidor; ¡claramente esto es malo si se le ingresa!):

  1. Obtenga una lista de los módulos de interfaz que se utilizan:

cat /etc/udev/rules.d/70-persistent-net.rules | grep "PCI device" | perl -pe 's/.*\((\w+)\).*/$1/g'| uniq

En mi caso, es igb, así que imprime solo eso.

  1. tipo sudo rmmod igb(reemplace igbcon su controlador de tarjeta obtenido del paso 1.

a continuación, edite /etc/udev/rules.d/70-persistent-net.rulessegún sea necesario, luego cargue el módulo nuevamente usando modprobe igb, nuevamente reemplazando igbcon el suyo.

Clayton Dukes
fuente
Esto, combinado con la respuesta de Otheus, fue la salsa secreta que me permitió arreglar la configuración de mi tarjeta de red Mellanox sin reiniciar la máquina. Creo que la carga del controlador y la lectura de udevadm del archivo persistent-net.rules es similar a lo que hace el sistema cuando se inicia.
Mike S
0

en caso de redes múltiples

cat /etc/udev/rules.d/70-persistent-net.rules | grep "PCI device" | awk '{print $NF}'|sed -e 's/(//g' -e 's/)//g'| uniq > /tmp/listnet
rm -rf /etc/udev/rules.d/70-persistent-net.rules 
for i in $(cat /tmp/listnet); do rmmod $i; modprobe $i;done
service network restart
rm -rf /tmp/listnet
alex tmp
fuente