dcc@world.std.com (Dave C Curado) (02/17/91)
I've got a question concerning a modem. I think there's probably a simple
solution to my problem, but since I don't know it yet...
We have a 386 running ICS 3.2 as an internet node. Unfortunately for me,
it's located 70 miles away from our main site, and we must always call
in to the machine via good ol' 2400 baud modems. This works fine, until
you have the occasion to drop the session in an ungraceful sort of way...
as in, hanging up the phone. (for various reasons)
When this happens, it seems as if the modem freeks out and sits there
trying to communicate with the shell process I've left running. This ties
up the machine so badly, that you can't login. Even standing at the console!
280 miles later, (two round trips to go and fix the problem)
my tires and I are looking for a 'better way.'
Some ideas we've had:
- alter the kernel resources to only give so many resources to a process
- try to make a daemon that would watch for this sort of tie up, and would
kill the process.
- be very very careful when dialing in (not so easy during thunder storms)
Dave C.
--
Dave Curado I didn't say that I didn't say it.
dcc@world.std.com I said that I didn't say that I said it.
Omnet Inc. I want to make that very clear
--former Mich. gov. George Romneyjimmy@icjapan.info.com (Jim Gottlieb) (02/18/91)
In article <1991Feb17.122852.26711@world.std.com> dcc@world.std.com (Dave C Curado) writes: > >and we must always call >in to the machine via good ol' 2400 baud modems. This works fine, until >you have the occasion to drop the session in an ungraceful sort of way... >When this happens, it seems as if the modem freeks out and sits there >trying to communicate with the shell process I've left running. This can usually be avoided by keeping the modem set to echo off (ATE0). This has solved all of our "deadly embrace" problems. Also make sure that the modem drops CD and DSR upon loss of carrier. But on to the broader subject... >280 miles later, (two round trips to go and fix the problem) >my tires and I are looking for a 'better way.' > Some ideas we've had: > - try to make a daemon that would watch for this sort of tie up, and would > kill the process. We have voice mail machines sitting in closets all around the country. There is no one there to help out if anything goes wrong, and I don't like hopping a train or plane to go reboot a hung machine. So we have many failsafes. We designed and built a board that sits connected to the speaker leads of the machine. A daemon process sends a beep to the speaker every minute. If the board goes for 10 minutes or so without hearing the beep, it shorts the reset leads together. This takes care of a total machine hang. Of course we also modified /etc/dumpsave so that the machine will always reboot. We are a large consumer of X-10 modules. These are devices that plug into the wall and can be controlled by (among other means) a remote telephone call. We plug the computer and the modem each into their own X-10 appliance modules. This allows us to power down and back up the modem (first resort) or the computer (last resort). Our medium resort is the X-10 module that gives a momentary contact closure. This is bridged across the reset leads. I would much rather just do a hard reset than a powerdown (basically pulling the plug), but sometimes the voice boards get into a state where they need to be powered down. By using these methods, most field visits can be avoided. Radio Shack carries X-10 products under the name "Plug'n'Power", but I don't think they carry the Telephone Responder. You can contact X-10 directly on 800-526-0027 or +1 201 784 9700, but you'll pay full list. -- Jim Gottlieb Info Connections, Tokyo, Japan E-Mail: <jimmy@denwa.info.com> or <attmail!denwa!jimmy> Fax: +81 3 3237 5867 Voice Mail: +81 3 3222 8429
rob@xyzoom.info.com (Rob Lingelbach) (02/19/91)
In article <393@icjapan.uucp> jimmy@denwa.info.com (Jim Gottlieb) writes: [stuff about using X-10 devices to control voicemail systems remotely deleted] >Radio Shack carries X-10 products under the name "Plug'n'Power", but I >don't think they carry the Telephone Responder. You can contact X-10 >directly on 800-526-0027 or +1 201 784 9700, but you'll pay full list. DAK in Canoga Park, CA also was carrying X-10 products the last time I checked. Heathkit's catalog I believe has them as well, under another product name--but they are the same devices. Rob Lingelbach rob@xyzoom.info.com -or- {well-connected}!uunet!xyzoom!rob KB6CUN Compuserve: 71101,176 2641 Rinconia Dr L.A. CA 90068 voice: 213 464-6266 --------"'Tis pride that pulls the country down" (Shakespeare)-------
wolf@equinox.UUCP (Craig Kozel) (02/22/91)
In article <1991Feb17.122852.26711@world.std.com> dcc@world.std.com (Dave C Curado) writes: > >I've got a question concerning a modem. I think there's probably a simple >solution to my problem, but since I don't know it yet... > >We have a 386 running ICS 3.2 as an internet node. Unfortunately for me, >it's located 70 miles away from our main site, and we must always call >in to the machine via good ol' 2400 baud modems. This works fine, until >you have the occasion to drop the session in an ungraceful sort of way... >as in, hanging up the phone. (for various reasons) >When this happens, it seems as if the modem freeks out and sits there >trying to communicate with the shell process I've left running. This ties >up the machine so badly, that you can't login. Even standing at the console! >280 miles later, (two round trips to go and fix the problem) >my tires and I are looking for a 'better way.' It sounds like the modem isn't dropping DCD or the serial port's device driver isn't handling it correctly. I'd call the multiport card manufacturer and see if they know how to correct the problem. Maybe they have a new driver. It is not unheard of for serial card (intelligent) drivers to have just the problem you state. You mention having a daemon lying around in wait to take care of this problem. For the short term you might look at a script that logs out inactive users after a period of time (say half an hour or so). SCO Xenix has a variable, idle, built in that you can set. I'm not sure what the equivalent SystemV3.2 is -- but I've seen discussions of this on the net.