Reinicia o nut-driver quando os dados estão obsoletos, o dispositivo usb continua mudando

3

Eu tenho um LCD PowerWalker VI 850 conectado a um Raspberry Pi Modelo B + via USB. Eu tenho tentado usar o NUT para monitorá-lo, com muitos problemas. Primeiro, parece que a detecção de protocolo não estava funcionando bem, e desde então eu especifiquei protocol = mustek e parece que ele estabilizou parcialmente - agora toda vez que eu inicio o serviço de driver de porca ele realmente se conecta.

No entanto, outra peculiaridade é que, por algum motivo, o dispositivo USB continua mudando (por exemplo, de /dev/bus/usb/001/005 na inicialização para 006 ou 007 ) sem aviso ou causa aparente. Eu tentei contornar isso adicionando um parâmetro SYMLINK à minha regra do udev:

ACTION=="add", \
SUBSYSTEM=="usb", \
ATTR{idVendor}=="0665", ATTR{idProduct}=="5161", \
SYMLINK+="powerwalkerups" \
MODE="0660", GROUP="nut"

O que garante que /dev/powerwalkerups aponte sempre para o dispositivo de barramento correto. Mas - parece, pelo menos - sempre que o dispositivo USB muda de forma mágica, o driver da porca perde a conexão e eu recebo a maravilhosa mensagem "data stale". Apenas, agora, sempre que eu reiniciá-lo, ele realmente se conectará corretamente com um bom protocolo e funcionará. Mas eu tenho que manualmente systemctl restart nut-driver .

Existe uma maneira automática de fazer o NUT tentar reiniciar o driver se os dados ficarem obsoletos? Ou alguém pode recomendar um processo do tipo watchdog que fará isso por mim? Como o serviço não para de fato, systemd não vê o serviço como falho. Como posso tentar reiniciar o serviço pelo menos uma vez para ver se isso resolve a conectividade?

(Ou alguma ideia de como parar de desconectar em primeiro lugar?)

UPDATE

O tempo de atividade no meu host NUT agora é de 5 dias e o dispositivo USB subiu de 005 para 012. Por isso, estou executando o Icinga2 em outro host, e vou tentar reinicializá-lo serviço ... mas que requer acesso SSH do host Icinga ao host NUT :-P. Melhores ideias?

    
por S'pht'Kr 28.12.2016 / 21:15

1 resposta

0

Descobri algo ... já que meu problema estava conectado ao dispositivo USB mudando, e eu já tinha uma regra do udev acima, adicionei uma instrução RUN da seguinte forma:

ACTION=="add", \                                                                                       
SUBSYSTEM=="usb", \                                                                                    
ATTR{idVendor}=="0665", ATTR{idProduct}=="5161", \                                                     
SYMLINK+="powerwalkerups", \                                                                           
MODE="0660", GROUP="nut", \                                                                            
RUN+="/bin/systemctl restart nut-driver"

Isso reinicia o nut-driver não quando os dados ficam obsoletos, mas quando o dispositivo USB é reconectado (ou o que você chama de que está fazendo). Isso parece ter resolvido o problema.

    
por 09.01.2017 / 17:07