Início / unix / Perguntas / 547022
Accepted
AdminBee
Asked: 2019-10-16 23:30:09 +0800 CST

Garantir informações completas do udev em dispositivos filho ao consultar o pai

  • 772

Estou tentando implementar uma função personalizada que, ao anexar uma unidade USB, verifica todos os sistemas de arquivos que ela contém e, em seguida, executa operações com base no tipo de sistema de arquivos detectado. Eu segui o caminho "recomendado" para escrever uma udevregra que aciona um systemdserviço "oneshot" instanciado para o nó do dispositivo, que por sua vez executa o script de shell que "faz toda a mágica (TM)" (por razões de independência de plataforma, um compilado programa não foi considerado uma opção aqui).

ACTION=="add", SUBSYSTEMS=="usb", SUBSYSTEM=="block", ENV{DEVTYPE}=="disk", RUN{program}="/bin/systemctl start usb-drive-manager@$devnode.service"

com

[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/usr/local/bin/usb_drive_manager.sh attach %I
ExecStop=/usr/local/bin/usb_drive_manager.sh detach %I

Dentro do script de shell, executo um ls /sys/.../sdX/sdX*caminho no dispositivo da unidade para localizar quaisquer partições e, em seguida, consultar informações sobre essas partições chamando

udevadm info /dev/sdXn

(onde né o número da partição) para cada partição processada.

O problema agora é que, embora isso funcione durante os testes "coldplug" do script de shell, não funciona quando o script é acionado a partir da udevregra, porque no momento em que o udevevento para a unidade é processado, as informações sobre as partições na unidade são ainda não coletado pelo kernel, ou seja, a chamada para udevadm inforetorna apenas informações rudimentares:

P: /devices/.../block/sdb/sdb1
N: sdb1
E: DEVNAME=/dev/sdb1
E: DEVPATH=/devices/.../block/sdb/sdb1
E: DEVTYPE=partition
E: MAJOR=8
E: MINOR=17
E: SUBSYSTEM=block

e todas as informações relevantes, em particular as variáveis ​​de ambiente ID_FS_TYPEe estão (ainda) ausentes. ID_FS_LABELComo chamar udevadm settledurante o processamento de udeveventos é uma má ideia (e também não ajudou), e até mesmo um loop de pesquisa com 0,5s de sono entre as chamadas para udevadm infonão funcionou (demorou cerca de 1 minuto até que a informação estivesse finalmente disponível), eu estou um pouco perdido aqui.

Infelizmente, reescrever a udevregra para que ela se aplique a partições em vez de unidades também é indesejável, pois há casos em que as pessoas criam o sistema de arquivos em todo o dispositivo USB em vez de criar uma única partição que abrange todo o dispositivo que contém o sistema de arquivos.

A questão agora é se

  • é possível atrasar o processamento de uma udevregra para um determinado dispositivo até que todos os filhos desse dispositivo tenham sido processados, ou
  • há uma chamada de sistema que eu poderia usar dentro do script de shell que "espera" que todos os eventos filho (se houver! udev)

Acho que esta é uma pergunta bastante longa agora; toda a ajuda é muito apreciada.

shell-script

1 respostas

  1. Best Answer

    Depois de mais algumas pesquisas, que me apontaram para o uso de regras blkidno udev (veja, por exemplo , este artigo do ArchLinux-Wiki , infelizmente disponível apenas em alemão), descobri que chamando

    blkid -o udev -p /dev/sdXn

    ao invés de

    udeavdm info /dev/sdXn

    dentro do systemdscript -triggered é possível recuperar informações completas até mesmo sobre os dispositivos filhos do pendrive cuja regra "add" está sendo processada.

    Parece que a -popção aqui é a chave, pois muda para um modo de sondagem ativo no qual o dispositivo é realmente lido, em vez de depender de informações armazenadas em cache (por exemplo, a página de manual ou o código-fonte de blkid).

    A -o udevopção simplesmente serve para formatar a saída de maneira semelhante à udevadmchamada, embora não seja uma substituição 100% imediata, pois os rótulos identificadores principais da udevadmsaída (como E:, P:, etc.) estão ausentes aqui.

    • -1

relate perguntas