greil@guug.guug.de (Anton Greil) (04/20/91)
How to build a procedure in UNIX (e.g. System V.3), which supervises a modem
in a UUCP (BNU) environment?
A procedure, which is periodically called by cron (e.g. all 15 minutes),
to examine if a modem is usable or just used (by cu, uucico) and not hanging
in some undefined state.
If the modem or its UNIX environment is not ok, the procedure should do a
reset of the serial line and/or a reset of the (Hayes compatible) modem by
"Uutry -r -x9 modem" with a setup-entry in the "Dialers" file, and a reset
of ... (???)
If the resets are not possible for the procedure, it notifies the system
administrator. The modem port is to be used bidirectionally by uugetty.
_____________________________________________________________________
Radically asked:
Is the problem of supervising a modem solvable by an algorithm?
______________________________________________________________________
Because of the long coexistence of UNIX, UUCP, system administrators and modems
I'm full of hope to find some proofed solutions for this everyday problem !
Toni Greil, Muenchen (Germany)
greil@guug.guug.deles@chinet.chi.il.us (Leslie Mikesell) (04/23/91)
In article <658@guug.guug.de> greil@guug.guug.de (Anton Greil) writes: > >How to build a procedure in UNIX (e.g. System V.3), which supervises a modem >in a UUCP (BNU) environment? >A procedure, which is periodically called by cron (e.g. all 15 minutes), >to examine if a modem is usable or just used (by cu, uucico) and not hanging >in some undefined state. I've experienced more trouble with the unix tty device drivers over the years than with modems. That is, most of the times I've had a line hang, there wasn't anything that could be done software-wise to fix it except maybe re-boot the machine. >If the modem or its UNIX environment is not ok, the procedure should do a >reset of the serial line and/or a reset of the (Hayes compatible) modem by >"Uutry -r -x9 modem" with a setup-entry in the "Dialers" file, and a reset >of ... (???) You can determine how long a connection has been in progress by looking at the associated lockfile's modification time. Uugetty normally does not delete its lockfiles so you have to check for the PID mentioned in the lockfile still being active (a quick hack would be to run "echo ~. | cu -l device" to clear stale locks first). Most modern smart modems have a way to query their parameters, so you could make a Dialer entry that requested the list with a corresponding Devices entry and a modem "class", and run it with cu -d >file, then examine for the expected settings. >If the resets are not possible for the procedure, it notifies the system >administrator. The modem port is to be used bidirectionally by uugetty. >Because of the long coexistence of UNIX, UUCP, system administrators and modems >I'm full of hope to find some proofed solutions for this everyday problem ! This isn't going to help with problems on the unix side and may, in fact make them worse because of the increased contention. How about just using modems that have a built-in "drop connection if there is no data for a settable amount of time"? Les Mikesell les@chinet.chi.il.us