At 11:55 AM 2/14/2008, Martin McCormick wrote:
I wrote a C program several years ago that works and
logs output from a telephone switch to a file and runs in
I just opened /dev/ttyd0 for reading and it has run for
up to 1,000 days at a time, but it also
has issues as one might expect.
It can be killed if one of the incoming characters
happens to be an EOF (4) which is quite possible if somebody
umplugs or plugs in the cable and creates garbage on the line.
If you use fread to read the stream, you can test using feof or ferror and
conditionally keep reading depending on the condition.
You should add signal handling so the program is only killed when you want
it to be.
The data from the switch is ASCII with carriage
return/linefeed sequences so nothing really harsh goes on, but I
need to make it as bullet-proof as possible.
In addition, the actual data are 7-bit, odd parity with
1 stop. I basically ignored that fact last time and masked off
the MSB of each character and that's how it has been for 5
Now, I am writing a similar program to log different
data from that same telephone switch and I want to do better
this time, but not reen vent any wheels I don't have to.
What is the best way to use as much of the existing UNIX
environment as possible to listen to /dev/ttyd[x] with no
interpretation of incoming data?
The data will be dumped at the end of each line, stored
in a file, and other action may be taken but normally, the
program will just be in a receive-blocked mode, waiting to hear
About the only thing I am doing differently this time is
trying to set the tty such that it doesn't look for any EOF or
other control codes in the data. The data will be treated as raw
and what ever comes across is okay. The program will clean it up
to make it good for the file.
You still need to handle when the cord is unplugged, or put the server in a
secure location away from other people.
As I stated, the standard /dev/ttyd device has done
amazingly well in FreeBSD4.7, but some of that has been dumb
luck. We shouldn't have to warn people in the area that they
could kill the logger by unplugging the cable since they
wouldn't be aware that they stopped it until we found out later
when there was nothing in the file.
Searching archives dealing with serial communications
produced good information about dialup lines and terminals, but
this is actually less complex.
Many thanks for any good advice about stty or anything
else that will allow one to use standard devices for this
If you want the program to be more capable of staying running you can have
the program fork a child and if the child dies, fork a new child. This is
the method used for many running services. Just be sure if the child dies
the log file is closed and that same file is opened by the new child.
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
email@example.com mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"