O script é executado de forma diferente se executado a partir do udev

Question

Estou tendo um problema com um script que parece muito estranho; parece parar de executar prematuramente quando executado a partir do udev, mas não quando eu o executo manualmente a partir da linha de comando. Eu tentei solucioná-lo com o set -x e quando eu corri-lo a partir da linha de comando tudo é executado como esperado. No entanto, quando é executado a partir do udev, ele pára prematuramente depois de um certo ponto.

Parte do problema, eu acho, é que é difícil depurar o script quando ele é executado pelo udev. Eu tentei colocar em logger declarações, mas eles basicamente me dizem a mesma coisa (que pára prematuramente).

Você vê alguma coisa que esteja causando esse problema?

O script (s) pode ser encontrado aqui . Uma nota sobre eles, eles são destinados a um sistema embarcado. Quando executado manualmente a partir da linha de comando, o comando que eu corro é:

./product.sh -b update /dev/sda1

A regra do udev que executa o script é:

ACTION=="add", KERNEL=="sd?1", RUN+="/usr/sbin/product.sh -b update /dev/%k"

O script parece parar nas linhas 195 ou 197 em product.sh . Eu notei que se eu comentar linhas 22 e 28 em product-manifest.sh , tudo é executado como esperado quando executado pelo udev e manualmente na linha de comando.

    

Answer 1

Ok, acho que descobri o problema. Acho que o problema é o resultado da linha 157 para onde estou redirecionando a saída para um arquivo; esse arquivo passa a ser uma unidade USB montada. Eu estou supondo que o redirecionamento é feito simultaneamente, e quando product-manifest.sh está completo, o script continua, levando, eventualmente, a desmontar a unidade USB antes que a gravação simultânea na unidade USB seja concluída. E quando o umount ocorre simultaneamente, ocorre algum erro que termina prematuramente o script.

A correção foi redirecionar a saída para o cartão SD e, em seguida, cp para copiá-lo para a unidade USB:

product-manifest.sh > "/tmp/MANIFEST"
cp "/tmp/MANIFEST" "$1"

Obrigado ao @mikeserv por me apontar na direção certa.