_Robust_ bluetooth serial port console/tty

Question

I've managed to create and connect to a console via bluetooth, as is described in many Q&A's FAQs Guides etc found via a google search.

Briefly, in sudo mode,

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

That's all well and good if the bluetooth connection is stable.

My question is how to make this more robust for a headerless system (raspberry pi). If the bluetooth connection is lost, I find myself having to reboot the headerless system. There may be several (non-concurrent) users on the system, and it will be inevitable that one of the users will walk out with the bluetooth client device without logging off first, leaving the next user unable to log in!

Slight edit: a possible ugly workaroud would be to monitor for dropped connections and then kill/restart the appropriate processes. Not sure what the best way of doing this would be (not sure the correct processes to kill (after killing rfcomm, new connections can't be made)) nor the correct thing to monitor(tty and/or bluetooth disconnects?)!

Answer 1

OK, I've come up with a solution myself - it might not be optimal though, so and comments and advice appreciated.

Following on from my 'slight edit', I wrote a script to monitor the rfcomm connection and if the bluetooth is disconnected but the tty is still attached, then kill the processes on the device:

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

I then added the script to crontab:

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

Seems to work, but with minimal testing. Not sure how robust it is!