Como depurar uma regra do udev (em /etc/udev/rules.d/…)

15

Estou criando uma nova regra básica

/etc/udev/rules.d/10-myrule.rules

contendo:

KERNEL!="sdb*", GOTO="auto_mount_end"
ACTION=="add", RUN+="/usr/bin/mount /dev/sdb1 /media"
LABEL="auto_mount_end"

Salvei, reiniciei e inseri um cartão SD (reconhecido por /dev/sdb1, eu o vejo dmesg), mas nada acontece. Quando eu faço manualmente mount /dev/sdb1 /media, ele funciona.

Como posso solucionar / depurar essa udevregra?

Nota: Estou usando o ArchLinux, mas deve ser o mesmo em qualquer distro?

arch-linux mount udev

— Basj
fonte

1

Altere o nome do arquivo para 99-myrule.rules...

— jasonwryan

@jasonwryan: o mesmo: nada acontece. Como solucionar problemas de uma regra do udev? Devo acioná-lo manualmente (como neste caso?)

— Basj

Muda systemdalgo para o comportamento normal do udev?

— Basj 4/15

1

tente udevadm monitor, veja isso e isso #

— Aquarius Power

1

O AFAIK não precisa ser reinicializado para que o udev leia novamente as regras (consulte unix.stackexchange.com/a/39371/44760 ). Eu fiz minha depuração do udev (que de fato não é a tarefa mais fácil!) Com udevadm testregras validadas e contra a realidade com udevadm info.

— precisa saber é o seguinte

11

10-como mencionado por jasonwryan, use numeração alta (bom dos anos 90). Então você regra não será substituída por outra.
Use as teclas mínimas exatamente como você realmente precisa. Exemplo, !=& GOTO/ LABEL, em vez disso, use diretamente==
```
ACTION=="add", KERNEL=="sdb*", RUN+="/usr/bin/mount /dev/sdb1 /media"
```
Seu alvo estava sdb1com comando fixo, minimize a correspondência cega usandoKERNEL=="sdb1"
Acho útil criar uma regra de depuração de sombra, chamei de sombra porque sempre a deixo lá no mesmo arquivo, então uso-a quando preciso.
```
ACTION=="add", KERNEL=="sdb*", RUN+="/bin/sh -c 'echo == >> /home/user/Desktop/udev-env.txt; env >> /home/user/Desktop/udev-env.txt'"
#ACTION=="add", KERNEL=="sdb*", RUN+="/usr/bin/mount /dev/sdb1 /media"
```
Nota: udev-env.txt é criada e a regra é acionada de qualquer maneira. Linha==correspondente a um nó correspondente. O ENV registrado nesse arquivo pode ser uma mistura entre 2 nós ou mais, criado quase ao mesmo tempo, é umstdoutproblema de buffer.
Use udevadm monitor -u, udevadm test ...e udevadm trigger ... para verificar quais as regras processados os eventos.
Dentro dos scripts, cabe a você fazer o log de depuração e capturar os comandos com falha, salvando também o valor de retorno stdoute as stderrmensagens.

Atualizar:

Referência: udev_237 - man udev (Ubuntu_18.04)

RUN{type}

Note that running programs that access the network or mount/unmount filesystems is not
allowed inside of udev rules, due to the default sandbox that is enforced on
systemd-udevd.service.

— user.dz
fonte

1

Muito útil. Alguns comentários udevadm test...parecem mostrar apenas variáveis de ambiente, para que ATTRSvocê possa usar udevadm info $DEVICEpara encontrar essas outras configurações.

— Att Righ

1

Em udevadm inforetornos, uma árvore de dispositivos deve ter cuidado ao distinguir configurações entre um dispositivo e seus dispositivos pai (as propriedades parecem ser herdadas se não forem substituídas). No meu caso, o subsistema estava errado.

— Att Righ

udevadm test "This program is for debugging only, it does not run any program specified by a RUN key. It may show incorrect results, because some values may be different, or not available at a simulation run."

Não há como rastrear o que realmente está acontecendo?

— Março

@ MarcH, você pode usar udevadm monitor -upara verificar eventos / condições e udevadm trigger ...testar suas ações.

— user.dz

@ MarcH, mas dentro dos scripts cabe a você fazer o log de depuração e capturar os comandos com falha (salvando o valor de retorno também as mensagens stdout & stderr).

— user.dz

1

Eu acho que o comando que você está procurando aqui é udevadm. Você usará os parâmetros triggere testpara acionar uma nova varredura dos eventos do udev e para testar um evento específico, respectivamente.

Aprendi isso da maneira mais difícil ao brincar com o novo dispositivo de rede nomeado no EL 7. Boa sorte!

— Paulo
fonte

1

Crie um arquivo de regras do udev

sudo nano /etc/udev/rules.d/99-removable-sd.rules

Adicione uma regra que diga aos udiscos para montá-la automaticamente
```
SUBSYSTEM=="block", SUBSYSTEMS=="mmc", DRIVERS=="mmcblk", ATTRS{type}=="SD", ENV{UDISKS_AUTO}="1", ENV{UDISKS_SYSTEM}="0"
```
ATTRS{type}=="SD" pode não ser necessário se você estiver usando tipos diferentes.
Regras de recarga
```
sudo udevadm control -R
```
Ejete e depois recoloque.

Referência: Archlinux Wiki: Alguns dispositivos, que devem ser tratados como removíveis, não são

— user.dz
fonte

0

Eu estava tendo o mesmo problema com FRAMBOESA PI 3 B +, é possível que os comandos acima possam ajudá-lo. Mas isso não me ajudou. Eu estava tentando invocar um script para inserir um dispositivo de armazenamento USB. As regras não são registradas no syslog; portanto, fica muito difícil entender qual regra funcionou ou qual falhou.

Então eu fiz o seguinte:

(1) Criei meu arquivo de regras em /etc/udev/rules.d/100-myrule.rules

(2) então eu executei o comando sudo /etc/init.d/udev restart

então eu verifiquei se funcionava. Uma informação pode ser útil para você ou não, mas os sistemas de arquivos são somente leitura para o udev até que o comando em (2) seja executado.

— MSharq
fonte