acp@ms.uky.edu (ACP Network) (01/17/90)
One of our uucp sites is having trouble with uucico. We (ukma) call it
every day to exchange netnews and mail, but frequently uucico locks up
on his end. The machine with the problem is an AT&T 6386 WGS running SysV/386
version 3.1 (or possibly 3.2) with HDB uucp (the standard AT&T distribution);
the machine that always calls it is a vax running ultrix and Version 2 uucp.
The modems on both ends are Telebit T-1000's connecting in an MNP mode.
The call takes place around 4 or 5 AM; when the sysop arrives in the
morning, he finds that uucico hung during the call and is still running
(the phone connection is broken). Uucico can be killed, but the uugetty
refuses to give up the line, and in fact is immune to kill -9. He has
to shut down the machine & restart to get the serial port back.
Here is a sample of the /usr/spool/uucp/.Log/uucico/ukma file from a crash
(with inserted line breaks):
uucp ukma (1/10-5:33:37,5057,0) OK (startup)
uucp ukma (1/10-5:33:39,5057,0) REMOTE REQUESTED
(ukma!D.ukmaBYs32 --> acpunc!D.ukmaSYs32 (netnews))
uucp ukma (1/10-5:34:00,5057,1) REMOTE REQUESTED
(ukma!D.ukmaXYs30 --> acpunc!X.ukmaAYs33 (netnews))
uucp ukma (1/10-5:34:04,5057,2) REMOTE REQUESTED
(ukma!D.ukmaBYs42 --> acpunc!D.ukmaSYs42 (netnews))
uucp ukma (1/10-5:34:43,5057,3) REMOTE REQUESTED
(ukma!D.ukmaXYs40 --> acpunc!X.ukmaAYs43 (netnews))
uucp ukma (1/10-5:34:46,5057,4) REMOTE REQUESTED
(ukma!D.ukmaBYs52 --> acpunc!D.ukmaSYs52 (netnews))
netnews ukma (1/10-5:36:41,5057,5) IN SEND/SLAVE MODE (INPUT FAILURE)
netnews ukma (1/10-5:36:41,5057,5) FAILED (conversation complete)
A few other items of note:
1) The lockup is intermittent, though it's been getting worse.
2) Other 6386s use the same uucp configuration files, the same modem,
and are called by the same site without trouble (or, at least not
this much trouble).
3) The modem on the 6386 has been replaced; this did nothing to fix the
problem.
I assume the uugetty is the actual culprit, since it becomes unkillable
(and uucico has enough wits to finish writing its log file).
Does anyone have any suggestions? Also, does anyone know how uugetty
becomes unkillable and what could be done to remove it without rebooting?
Please write me directly instead of posting, since I've crossposted
to three groups. I'll summarize & post if there's any interest.
Kenneth Herron
--
acp@ms.uky.edu University of Kentucky ACP Network Consultant
ukma!acp Dept. of Mathematics, room 715 POT (606) 257-2975
Lexington, KY 40506bdb@becker.UUCP (Bruce Becker) (01/18/90)
In article <13698@s.ms.uky.edu> acp@ms.uky.edu (ACP Network) writes: |One of our uucp sites is having trouble with uucico. We (ukma) call it |every day to exchange netnews and mail, but frequently uucico locks up |on his end. The machine with the problem is an AT&T 6386 WGS running SysV/386 |version 3.1 (or possibly 3.2) with HDB uucp (the standard AT&T distribution); |the machine that always calls it is a vax running ultrix and Version 2 uucp. |The modems on both ends are Telebit T-1000's connecting in an MNP mode. First of all, why are you running T1000's in MNP mode, when you could be using the much more reliable & faster PEP mode? |The call takes place around 4 or 5 AM; when the sysop arrives in the |morning, he finds that uucico hung during the call and is still running |(the phone connection is broken). Uucico can be killed, but the uugetty |refuses to give up the line, and in fact is immune to kill -9. He has |to shut down the machine & restart to get the serial port back. The modem and the driver may be in a mutually impossible state. Things to try - Configure the Telebit to run in autobaud mode, i.e., don't lock the interface speed (set S66=0). Try setting modem register S52=2 if not already done. This causes the modem to reset to its defaults when it sees DTR drop. Make sure S53 is nonzero, so that DCD signal will indicate carrier state. In the gettydefs, remove the "ECHO" keyword from the first section of the applicable entry. Try turning the modem off and then kill the uugetty when trying to get out of the lockup state. If this doesn't work you may have a hardware problem such as a bad serial port or modem cable. It's less likely to be software if you have other systems running the same configuration without this problem. -- ,,,, Bruce Becker Toronto, Ont. w \$$/ Internet: bdb@becker.UUCP, bruce@gpu.utcs.toronto.edu `/c/-e BitNet: BECKER@HUMBER.BITNET _/ >_ "Money is the root of all money" - Adam