Como recarregar as regras do udev sem reiniciar?

210

Como recarregar as regras do udev, para que um recém-criado possa funcionar?

Estou executando o Arch Linux e não tenho um udevstartcomando aqui.

Também verificado /etc/rc.d, nenhum serviço udev lá.

kernel udev

— margarida
fonte

1

Observe que as versões mais recentes do udev descartaram o suporte à inotify, de modo que o recarregamento das regras sobre alterações é necessário com mais frequência nos dias de hoje.

— Colin Guthrie

O que é udev? É o gerente de /dev?

— Sandburg

1

@ Sandburg sim, ele lida com plug-n-play em sistemas Linux.

— Aaron D. Marasco 26/03

231

# udevadm control --reload-rules && udevadm trigger

— Ignacio Vazquez-Abrams
fonte

4

Você precisa udevtriggerdepois?

— Nils

38

@ Nils Na verdade, você pode precisar udevtrigger(ou melhor, udevadm triggerna maioria das distribuições) (isso ou conectar o dispositivo e instalá-lo). --reload-rulesé quase sempre inútil, pois acontece automaticamente.

— Gilles

12

udevadm triggerfiz o truque no CentOS 6 para mim.

— Astrostl

3

udevtriggerou udevadm triggernão funcionou para mim. Descobri que alguns dispositivos funcionarão após descarregar e carregar o módulo para o mesmo (assumindo que seja o módulo carregável). O que eu descobri é que não é necessário necessariamente reiniciar o sistema. Exemplo para um dispositivo de rede, eu rmmod ixgbe, rmmod tg3, rmmod e1000em seguida modprobe ixgbe, modprobe tg3, modprobe e1000dependendo do tipo de controlador de rede.

— enthusiasticgeek

1

Nenhuma das coisas mencionadas entre as respostas funcionou para mim no Debian Jessie (8.0). A coisa que funcionou é ip link set $oldname name $newnamemencionada aqui . No meu caso, eu precisava substituir um iface nomeado lanpor iface em ponte (para KVM) e, portanto, o iface original - agora subjacente - precisava recuperar seu nome antigo eth1. Então o truque foi: 1) derrubar o iface; 2) corrigir configuração da rede; 3) atualizar o arquivo de regras de nomeação do udev; 4) renomeie o iface usando ip link...; 5) levante a ponte.

— kostix

69

O Udev usa o mecanismo inotify para verificar alterações no diretório de regras, na biblioteca e nas árvores de configuração local (normalmente localizadas em /lib/udev/rules.de /etc/udev/rules.d). Portanto, na maioria das vezes, você não precisa fazer nada ao alterar um arquivo de regras.

Você só precisa notificar o daemon udev explicitamente se estiver fazendo algo incomum, por exemplo, se você tiver uma regra que inclua arquivos em outro diretório. Em seguida, você pode usar a convenção usual para solicitar que os daemons recarreguem sua configuração: envie um SIGHUP ( pkill -HUP udevd). Ou você pode usar o udevadmcomando: udevadm control --reload-rules.

Entretanto, lembre-se de que versões diferentes do udev têm historicamente diferentes gatilhos para recarregar as regras automaticamente. Portanto, em caso de dúvida, ligue udevadm control --reload-rules: não fará mal nenhum.

As regras do udev são aplicadas apenas quando um dispositivo é adicionado. Se você deseja reaplicar as regras a um dispositivo que já está conectado, é necessário fazer isso explicitamente, chamando udevadm triggercom as opções corretas para corresponder ao (s) dispositivo (s) cuja configuração foi alterada, por exemplo udevadm trigger --attr-match=vendor='Yoyodyne' --attr-match=model='Frobnicator 300'.

— Gilles
fonte

1

O systemd udev usa o inotify para observar mudanças nas regras?

— Craig McQueen

O inotifymecanismo nem sempre captura uma alteração de um arquivo de regras do udev. Por exemplo, quando eu uso cat > 10-name.rulespara alterar o arquivo de regras colando o conteúdo, preciso recarregar as regras manualmente usando udevadm. Testado em Raspbian Stretch.

— Daniel K.

@DanielK. Isso mudou recentemente? IIRC Eu verifiquei um udev systemd e um udev não systemd quando publiquei esta resposta, e ambos usaram inotify, por isso --reload-rulessó era necessário em casos incomuns.

— Gilles

@ Gilles: talvez meu exemplo acima (sobrescrevendo um arquivo de regras existente usando o redirecionamento de shell) possa ser considerado um "caso incomum". Quando modifiquei esse arquivo por meio de um editor, por exemplo, vi, o inotifymecanismo funcionou.

— Daniel K.

@DanielK. Ah, é bom saber. Não é um caso incomum: alguns editores salvariam o arquivo reescrevendo (com o Vim e o Emacs, depende de como eles estão configurados). Estranho que o udev lide apenas com um dos casos - me parece um bug, porque não consigo pensar em um motivo para tratá-los de maneira diferente.

— Gilles

19

Estou adicionando isso porque um dia vou precisar ... de novo.

Às vezes, você obtém uma correspondência incorreta de números de dispositivos Ethernet e endereços MAC. Às vezes isso é realmente importante, como ao executar em uma VM e cada dispositivo é atribuído a uma VLAN diferente.

Desative as interfaces de rede e, em seguida,
modificar /etc/udev/rules.d/70-persistent-net.rules(ou equivalente)
recarregar com udevadm control --reload-rules
reativar com udevadm trigger --attr-match=subsystem=net
trazer as interfaces de rede.

Fiquei surpreso com o quão bem isso funcionou.

— Otheus
fonte

6

na Red Hat:

service network stop && udevadm control --reload-rules; udevadm trigger --attr-match=subsystem=net; service network start

— Alexander Torstling

1

Nos testes da Debian, o 'udevadm trigger --attr-match = subsystem = net' não funciona. Eu tive que desconectar e conectar a placa ethernet usb, só então o udev acionou uma nova regra.

— Trismegistos

Eu estaria disposto a apostar, Trismegistos, que o plugue / desligamento é semelhante a remover e recarregar o driver de rede, conforme resposta de Clayton Dukes.

— Mike S

12

Não tenho certeza se isso se aplica, e este é definitivamente um post mais antigo, mas surgiu bastante bem minha pesquisa na web por informações do udev, então pensei em compartilhar algum conhecimento.

Você pode disparar regras do udev manualmente para dispositivos específicos. Isso se aplica apenas a distros relacionadas ao redhat (centos fedora etc etc etc)

Depois de fazer as alterações relevantes no seu arquivo de regras ( /etc/udev/rules.d/whateveryoucalledyourrules), você poderá ecoar changeno evento do dispositivo.

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

Isso forçará a leitura de uma regra do udev APENAS para este dispositivo. Muito melhor e mais direcionado na minha opinião.

— mbadmin
fonte

4

Para mim, a sequência de comandos abaixo funcionou como desejado.

Fiz modificações /etc/udev/rules.d/70-persistent-net.rulespara alterar o ethnúmero e recarregá-lo sem 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

Seguindo isso, ele foi carregado com êxito em tempo de execução sem reiniciar a máquina.

Qualquer sugestão ou recomendação sobre isso é bem-vinda, pois eu descobri isso sozinho lendo as páginas de manual.

— Aditya Malviya
fonte

2

Estou adicionando a resposta correta aqui, porque demorei um pouco para notá-la no comentário de @enthusiasticgeek. Tudo o que você precisa fazer (supondo que você esteja no console do servidor - claramente isso é ruim de fazer se você estiver no ssh!):

Obtenha uma lista dos módulos de interface que estão sendo usados:

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

No meu caso, é igb, então imprime exatamente isso.

tipo sudo rmmod igb(substitua igbpelo driver da placa obtido na etapa 1.

Em seguida, edite /etc/udev/rules.d/70-persistent-net.rulesconforme necessário e carregue o módulo novamente usando modprobe igb, substituindo novamente igbpelo seu.

— Clayton Dukes
fonte

Isso, combinado com a resposta de Otheus, foi o molho secreto que me permitiu corrigir a configuração da minha placa de rede Mellanox sem a reinicialização da máquina. Acredito que o carregamento do driver e a leitura do udevadm do arquivo persistent-net.rules sejam aproximadamente semelhantes ao que o sistema faz quando é inicializado.

— Mike S

0

no caso de várias redes

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
fonte