I have a high-availability cluster (Heartbeat) connected via serial line and two ethernet NICs. I'd like to set up a monitoring script capable of recognizing disconnected serial line (basically the same question was answered at SO, however I am not satisfied with such a general answer).
I cannot simply open the serial device and read the data myself, since the serial line is opened by Heartbeat.
So I started to look for some indirect clues. The only difference I have found so far is in the contents of /proc/tty/driver/serial. This is how it looks like when it's connected:
# cat /proc/tty/driver/serial
serinfo:1.0 driver revision:
0: uart:16550A port:000003F8 irq:4 tx:2722759 rx:2718165 brk:1 RTS|CTS|DTR|DSR|CD
And when disconnected:
# cat /proc/tty/driver/serial
serinfo:1.0 driver revision:
0: uart:16550A port:000003F8 irq:4 tx:2725233 rx:2720703 brk:1 RTS|DTR
I'm not confident enough to decide that the signals listed at the end of the line have the very meaning of connected/disconnected cable as I have not found any documentation on the contents of the /proc/tty/driver/serial. I can only assume that the presence of the signal means the given signal is on "right now" (or was in recent past? or?). The Serial HOWTO says that additional signals present when the cable is connected (CTS flow control signal, DSR "I'm ready to communicate", CD "Modem connected to another") are all in the "input" direction. So there has to be somebody alive at the other end.
Assuming that meaning of signals is as described in the Serial HOWTO, I can base my decision on the presence of, say CD signal. However I am not really sure.
So the question is: is my method "right", or do I have any better options I am not aware of?
EDIT: I did some additional observations and had a talk with my colleague. Turns out the presence or absence of signals at the end of the line is quite good indicator of the serial port activity, on both ends. However, it's not an indicator of physical presence of a cable. Whenever there was a program writing to serial port outgoing signals were present (RTS|DTR). When the other side was writing incoming signals were present (CTS|DSR|CD). When none of the sides communicates there are no signals at all (that does not necessarily mean there is no cable present). Don't forget that the exact signals depend on the wiring of the cable (I have "null modem with partial handshaking").
RS232 has no "cable presence" indicator of any kind. You're just getting transmission or metadata (control) signals through, or you don't - that's all you know. If you receive an incoming signal (CTS|DSR|CD) you know the cable is connected. If you don't receive any incoming signal, the state of the cable is indeterminate and there is no way to determine if it's plugged in without additional hardware solutions - or performing some kind of exchange with the remote device.
The usual approach is performing some kind of "keep-alive" transmissions (even just metadata - e.g. momentarily set DTR and expect CTS) but if the discipline of protocol used by software at the two ends of the cable forbids such idle exchange, you're pretty much stuck with using a soldering iron to proceed.
What you might try, is some kind of additional "demon" that sets up a pipe, forwarding data between your software and the physical device (on both ends), encapsulating it - and performing "connection checks" if the pipe is idle.
Let me add one rather common solution: if your endpoint device doesn't use hardware control, you can short DTR with CTS inside the plug on the host side and use 'hardware control' on the host side. Generating DTR automatically drives CTS, enabling the transmission, if the cable is present, so transmission is unaffected. Meanwhile, with cable absent, the system will react to lack of CTS in a manner appropriate to this event, e.g. generating a timeout or suspending transmission until the cable is plugged in.
Collected from the Internet
Please contact [email protected] to delete if infringement.
Comments