_Robust_ console de porta serial bluetooth / tty

Question

Consegui criar e conectar-me a um console via bluetooth, conforme descrito em muitos Guias de FAQs de Perguntas e Respostas, etc., encontrados por meio de uma pesquisa no google.

Resumidamente, no modo sudo,

/usr/sbin/hciconfig hci0 piscan
/usr/bin/sdptool add --channel=3 SP
/usr/bin/rfcomm watch /dev/rfcomm0 3 /sbin/agetty rfcomm0 9600 vt100

Tudo isso é bom se a conexão Bluetooth estiver estável.

Minha pergunta é como tornar isso mais robusto para um sistema sem cabeçalho (raspberry pi). Se a conexão Bluetooth for perdida, eu tenho que reiniciar o sistema sem cabeçalho. Pode haver vários usuários (não simultâneos) no sistema, e será inevitável que um dos usuários saia com o dispositivo cliente bluetooth sem fazer logoff primeiro, deixando o próximo usuário incapaz de efetuar login!

Ligeira edição: uma possível workaroud seria monitorar as conexões perdidas e depois matar / reiniciar os processos apropriados. Não tenho certeza qual seria a melhor maneira de fazer isso (não tenho certeza se os processos corretos para matar (depois de matar rfcomm, novas conexões não podem ser feitas)) nem a coisa correta para monitorar (tty e / ou desconecta bluetooth?)!

    

Answer 1

OK, eu mesmo encontrei uma solução - talvez não seja a melhor, e os comentários e conselhos são bem-vindos.

Seguindo a minha 'pequena edição', eu escrevi um script para monitorar a conexão do rfcomm e se o bluetooth estiver desconectado, mas o tty ainda estiver conectado, então mate os processos no dispositivo:

check_rfcomm

rfcomm show /dev/rfcomm0 2>/dev/null | grep "channel 3 closed" | grep "tty-attached"
if [ $? -eq 0 ]; then
    kill -9 'lsof -t /dev/rfcomm0'
fi

Eu adicionei o script ao crontab:

* * * * * /usr/local/bin/check_rfcomm >>/var/log/check_rfcomm.log 2>&1

Parece funcionar, mas com testes mínimos. Não tenho certeza de quão robusto é!