root@mjbtn.UUCP (Mark J. Bailey) (05/23/88)
I just recently moved up from a Tandy 6000 running MicroSoft Xenix (Tandy
style) version 3.2 to SCO Xenix '386 2.2.2 on a Tandy 4000. I really
had no trouble to speak of, except for the fact that uucp is acting flakey
when it tries to use a line that is enabled (via UNGETTY) or when some-
thing bombs uucp when the port doesn't disable or the program is interrupted.
I know it sticks DIALOUT in /etc/utmp to make it look like "some one is
really using the port" to keep other process from grabbing it, but I find
that about at least once or twice a day, uucp either aborts or cannot start
for some reason, and DIALOUT gets left in utmp. After that, no one can use
it.
My question is, has anybody else experienced these odd behaviors, and if so
what have you done to work around or fix it. ALso, is UNGETTY really a
trustworthy program that I can sit back and forget about, I should I try
a bi-directional getty like uutty, or maybe some other alternative. Why
isn't there a UUGETTY for it already?
I had uucp working like a dream on the 6000 Xenix, but I am very concerned
about SCO uucp. It even will try and use the port (the dialer) when I am
logged in via a remote terminal and a modem. I understood from the dialer
code that that isn't supposed to happen either.
Any comments and assistance would be most appreciated.
Thank you.
Mark.
--
Mark J. Bailey "Y'all com bak naw, ya hear!"
USMAIL: 511 Memorial Blvd., Murfreesboro, TN 37130 ___________________________
VOICE: +1 615 893 4450 / +1 615 896 4153 | JobSoft
UUCP: ...!{ames,mit-eddie}!killer!mjbtn!root | Design & Development Co.
FIDO: Mark Bailey at Net/Node 1:116/12 | Murfreesboro, TN USAag@elgar.UUCP (Keith Gabryelski) (05/25/88)
In article <260@mjbtn.UUCP> root@mjbtn.UUCP (Mark J. Bailey) writes: >...[explaination of ports not getting reset]... > >My question is, has anybody else experienced these odd behaviors, and if so >what have you done to work around or fix it. Yes. See below. >ALso, is UNGETTY really a >trustworthy program that I can sit back and forget about. From dial(M): "If the specified line has been configured as a dial-in/dial-out line, dial invokes ungetty(M) to suspend the getty, makeing it a dial-out line. When the dial-out session is finished, dial should be called with the `-h' option to restore the dial-in line. (See ungetty(M).) If uucp or cu abort abnormally, the line will still be enabled for dial out. Use `who -a' to check the line status. If the serial line is still in a dial-out state, use `ungetty -r' to restore the dial-in line." I was given this advice when I queried a long-time SCO user. [From: Greg Laskin; Tue, 15 Mar 88 <8803152033.AA13831@gryphon.CTS.COM>] From Keith Gabryeslki, private mail to greg@gryphon >Hmmmm... This seems to be the problem, but LOGFILE does not record >any errors that may occured during the uucico invocation. Curious! > >In any case, I can not consistently recreate the problem, so I am >unsure on execatly why uucico aborts. > >Have you a clue? No. Ask: who were you talking to at the time. Is there a conversation complete in LOGFILE. Is there a core file in /usr/spool/uucp. Did you have any traffic for the site. Did they have any traffic for you. Was the traffic delivered. I've seen uucico core dump in 2.1.3 under some circumstances (remote requests file transfer after calling system had no traffic). I've never played with 2.2 uucp and ungetty. Try making more stack space for uucico - fixhdr -F 4000 uucico that's been know to help in earlier versions. The above didn't seem to help my problem too much. It may help you. I offer this shell script. I run it in cron under the account uucpadm every so often to fix any gettys that may be hosed. It is brute force, but until the problem is fixed, it is satisfactory. The code does keep a log in /usr/spool/uucp/FIXLOG of all gettys that had to be reset. Also, I've only seen this problem on the Anchor 2400E's that we have here, not of the USRobotics. There is probably an incompatibility that I haven't been able to detect with dialHA24??? Me thinks it doesn't drop disconnect when it should. But that is unfounded assumption. : # # Fix a hung getty. # # 3,18,33,48 * * * * /usr/lib/uucp/fixgetty >/dev/null 2>&1 # DIALOUTS=`who -a | grep DIALOUT | awk '{ print $2 }'` for i in $DIALOUTS do if test ! -f /usr/spool/uucp/LCK..$i then echo "`date` DIALOUT $i" >> /usr/spool/uucp/FIXLOG /usr/lib/uucp/ungetty -r $i fi done # # End of script # >I should I try a bi-directional getty like uutty, or maybe some other >alternative. Why isn't there a UUGETTY for it already? As far as I know, SCO Xenix will not run any getty except for /etc/getty. The field in /etc/inittab that specifies the getty to run is ignored. Hopefully this will be fixed in 2.3. >I had uucp working like a dream on the 6000 Xenix, but I am very concerned >about SCO uucp. It even will try and use the port (the dialer) when I am >logged in via a remote terminal and a modem. I understood from the dialer >code that that isn't supposed to happen either. Not sure what is happening here. Maybe you could elaborate? Dial should try to use the line only if the port is marked as LOGIN. What port are you logging in on? What port does the lockfile get made for in /usr/spool/uucp when dial runs? What happens on your screen when dial grabs your line? (I really) hope this helps. --Keith -- [ Keith ] UUCP: {ucsd, cbosgd!crash, sdcsvax!crash, nosc!crash}!elgar!ag [Gabryelski] INET: ag@elgar.cts.com ARPA: elgar!ag@ucsd.arpa
john@jetson.UUCP (John Owens) (05/25/88)
In article <154@elgar.UUCP>, ag@elgar.UUCP (Keith Gabryelski) writes: > What port are you logging in on? What port does the lockfile get made for > in /usr/spool/uucp when dial runs? What happens on your screen when > dial grabs your line? Just to elaborate a little: make sure that the port enabled for dialin in /etc/ttys and the port being used for dialout in /usr/lib/uucp/L-devices are *both* the modem control device (tty1A instead of tty1a for COM1, for example). -- John Owens SMART HOUSE Development Venture john@jetson.UUCP (old uucp) uunet!jetson!john +1 301 249 6000 (internet) john%jetson.uucp@uunet.uu.net
woods@gpu.utcs.toronto.edu (Greg Woods) (06/07/88)
This was supposed to be sent by mail, but I can't seem to convince uunet that it knows about "fozzy" even though uupath shows it does :-) $ uupath mjbtn ai.toronto.edu!uunet.uu.net!fozzy!killer!mjbtn ----- Transcript of session follows ----- 550 killer:root.tcp... 550 Host unknown 550 <@uunet.uu.net,@fozzy.uucp,@killer:root@mjbtn>... Host unknown: Inappropriate ioctl for device ----- Unsent message follows ----- > Date: Tue, 24 May 88 22:57:34 EDT > To: mjbtn!root > In-Reply-To: <260@mjbtn.UUCP> I'm running 2.2.1 Update B on 286's and 386's. Besides the other bugs in the Kernel, I've come across the same bug you mention with ungetty. I've written a script that surrounds uucico, and checks the port status after each run. The only problem is that all it can do is complain, since it can't kill the DIALOUT getty when it gets stuck. I don't want to do my polling as root, and su to run uucico. When I get the time, I'll write an suid program to do the assasination. I think the bug is in getty, as it happens to me with successfull calls, and not allways on bad calls. SCO don't seem interested in fixing it. SCO Xenix V 2.x.x uucp is based on a port of a VERY old V7 version. I doubt we will see anything new for the 286, unless from Microport, or Interactive, for quite some time (Maybe after System V Rel. 4.0 hits the bricks, though I hope the 286 is dead and gone by then!) Greg Woods. UUCP: utgpu!woods, utgpu!{cpcc, ontmoh, ontmoh!cpcc, tmsoft!cpcc}!woods VOICE: (416) 242-7572 [h] LOCATION: Toronto, Ontario, Canada -- Greg Woods. UUCP: utgpu!woods, utgpu!{cpcc, ontmoh, ontmoh!cpcc, tmsoft!cpcc}!woods VOICE: (416) 242-7572 [h] LOCATION: Toronto, Ontario, Canada