dragon@uw-june (Brian Matthews) (05/15/85)
We're using an ExorMacs with 2Meg as a uucp node. We're running uucp version 5.2 (I think). The problem is, if I start up uucico, or do a uupoll from a remote machine, and there are no jobs queued on either end, everything goes fine until the master uucico (running on the remote machine) tells the other to quit. The master finally times out, and by now the slave uucico on the ExorMacs is just sitting on the port. I kill the uucico, and a getty is spawned, but I can't kill it, even with a 9 (as superuser of course). The getty is always (at least when I've looked) running at priority one higher than the other gettys, so it doesn't look like its sleeping at priority less than PZERO (the usual cause of processes ignoring kill -9's). This occurs on both direct connect lines, and dial up lines, and on three different ports (and two different serial boards). Has anyone else seen this type of behavior, and have you fixed it? I'd particularly like a response from anyone at MicroSystems who might have some idea what's going on. I'm open to almost any suggestion, rewiring cables, rejumpering serial boards, hacking on serial drivers, getty, uucp, whatever. Currently the only way to fix the problem is to reboot the ExorMacs; not the easiest thing to do once an hour. If you have seen this (or even if you just know a lot about the workings of the universe), please mail to me at the address below (ignore the address in the header) with any suggestions. Thanx in advance for any help you can provide. Brian Matthews ...!uw-beaver!ssc-vax!cxsea(<-the offending machine)!arrakis!blm
clewis@mnetor.UUCP (Chris Lewis) (05/16/85)
In article <78@uw-june> dragon@uw-june (Brian Matthews) writes: >We're using an ExorMacs with 2Meg as a uucp node. We're running uucp >version 5.2 (I think). The problem is, if I start up uucico, or do a >uupoll from a remote machine, and there are no jobs queued on either >end, [ or even if the remote has stuff to send but the EXORmacs doesn't ] >everything goes fine until the master uucico (running on the >remote machine) tells the other to quit. The master finally times out, >and by now the slave uucico on the ExorMacs is just sitting on the port. >I kill the uucico, and a getty is spawned, but I can't kill it, even >with a 9 (as superuser of course). The getty is always (at least when Just a little extra from someone who has to communicate with Brian's site "cxsea" regularly: EXACTLY THE SAME behaviour is exhibited with the System V uucico that comes with the EXORmacs (V/68 rev 2.1 I think - right Brian?). We've tried putting sleeps around the ioctls that his uucico does (because of a suspicion of the EXORmacs tty drivers) but we usually end up with multiple defunct-ppid=1-but-invisible-to-init processes (seemingly another known problem with V/68). Our system is a Pyramid running 4.2 BSD uucp (probably the same "5.2 uucp"). This behaviour is NOT seen on a normal user login. ARGH! Any help would be greatly appreciated! Is anyone out there using EXORmacs uucp to any extent? ps: Hi Brian - I'm glad you have another uucp net connection. -- Chris Lewis, UUCP: {allegra, linus, ihnp4}!utzoo!mnetor!clewis BELL: (416)-475-8980 ext. 321
dragon@uw-june (Brian Matthews) (05/18/85)
Well, after some experimentation, I have some more info. It seems that
if the calling uucico is uucp 5.2, it hangs the port, no matter what
the answering uucp is on the ExorMacs. I compared the code of the SysV
uucico and the 5.2 uucico, and changed what looked like important
differences, and it worked! Sort of. The uucico now ALWAYS reports a
timeout (running it with -x4) after it has sent the final "OO 0", but
the uucico on the other end doesn't hang, it exits, and a normal getty
is spawned. Unfortunately, after a number transfers, init seems to
break, and any process created is made a zombie when it exits!
We have been in contact with MicroSystems, and they're looking into the
problem, but I'd appreciate any help anyone else can give.
Brian Matthews
...uw-beaver!ssc-vax!cxsea!arrakis!blm
PS: The code I modified was in cico.c, where things are coming to and
end. There is an 'if (!setjmp(jmpbuf)) {'. In this block is something
like 'omsg ("OOOOO 0", Ofn)' or something. It is this statement I
removed. Sorry I can't be more exact, but I'm typing this on a
different machine. If it matters I can look it up.