slb@slbtoy.UUCP (Sanford L. Barr) (03/30/88)
Hello world\n
I'm running into an annoying problem and I was hoping someone
could give me a hand. Any time I run uucico and connect with a local
system my uucico hangs at the end of the transfer. This is not the
old 3.51 uucico problem (I have the fixdisk).
The uucico process spawns a "getoff.sh" which then calls
"setgetty". The setgetty process seems to just hang in mid air. If I
kill it, everything returns back to normal. However, I can't figure out
what's making it hang! This is real annoying when you put mail in
the uucp qeue and all of the sudden uuxqt kicks in and starts processing
last night's news (meanwhile the other uucico is still hanging in mid air).
Anyone else come across this nasty?
San
--
///// Sanford L. Barr | Voice phone: (516) 246-6349
//// -- -- | Address (USnail):
/// {mtune, bc-cis }\ |
// {ihnp4, boulder} !icus!mozart!slbtoy!slb | ATRIS LTD
/ {talcott, sbcs }/ | 10 Kejaro CT
| Centereach, N.Y. 11720
Alternates: atc@bnl.ARPA, atc@bnl.BITNET | ATTN: Sanford L. Barr
--------------------------------------------------------------------------greg@csanta.UUCP (Greg Comeau) (04/03/88)
> I'm running into an annoying problem and I was hoping someone >could give me a hand. Any time I run uucico and connect with a local >system my uucico hangs at the end of the transfer. Do you have DTR and friends all wired up correctly on your local net? Perhaps one of the systems is not hanging up properly and thus the uucico hangs around. (On the other hand, uucico should also time-out after a minute or two of no activity). Are you running the uucico by "hand" or via cron?
sewilco@datapg.DataPg.MN.ORG (Scot E. Wilcoxon) (04/08/88)
In article <120@slbtoy.UUCP> slb@slbtoy.UUCP (Sanford L. Barr) writes: >... > The uucico process spawns a "getoff.sh" which then calls >"setgetty". The setgetty process seems to just hang in mid air. If I >... Setgetty has been hanging several times a week here. I had to make a daemon which kills any setgetty which has used "too much" CPU time. In crontab: 6 * * * * /bin/su root -c "/usr/local/bin/setg.clean" > /dev/null And what does the work (should use setgetty, but it has no documentation): # Test for a setgetty with a lot of CPU, kill it, and fix inittab SETGLINE=`ps -ef | fgrep setgetty` if [ -n "$SETGLINE" ] then CPTIME=`expr "$SETGLINE" : '.*:..:.. ... \(.*\):.. setgetty'` if [ ${CPTIME:-0} -gt 9 ] then echo $SETGLINE | mail root PROCID=`expr "$SETGLINE" : '^....... \(.....\) '` kill -9 $PROCID sleep 5 cp /etc/inittab /etc/inittab.new sed -e '/^:ph1/s/^:/ /' /etc/inittab >/etc/inittab.new mv /etc/inittab.new /etc/inittab sleep 15 telinit q fi fi -- Scot E. Wilcoxon sewilco@DataPg.MN.ORG {amdahl|hpda}!bungia!datapg!sewilco Data Progress UNIX consulting +1 612-825-2607 uunet!datapg!sewilco
slb@slbtoy.UUCP (Sanford L. Barr) (04/09/88)
Since I posted my original request for help I've received mail from a few other 3b1/7300 owners with the same problems. My situation is as follows - My site (7300) calls another local site (3b1) for a news feed. I'm running the standard UUCP that was distributed with the machine. The other site is running HDB UUCP. The transfer works fine... I receive all the incoming news. Then, when the machines are about to hangup, my machine spawns a "getoff.sh". "getoff.sh" is a shell script that calles "setgetty" which is supposed to take the getty off the modem line (why? I don't know - it should be spawning a new one insead shouldn't it?). Anyhow, the setgetty call hangs FOREVER - which causes the uucico process to wait around, which stops my news from being processed. My apologies if it's confusing - but that's what I see happening. The only solution I've come across so far is writing a little deamon that checks "ps" for any setgetty's that have been sitting around for over a minuite and kills them. Does anyone know what's causing this? Or am I going to have to try my hand at the AT&T hotline. San
jcs@tarkus.UUCP (John C. Sucilla) (04/11/88)
In article <121@slbtoy.UUCP> slb@slbtoy.UUCP (Sanford L. Barr) writes: >spawning a new one insead shouldn't it?). Anyhow, the setgetty call hangs >FOREVER - which causes the uucico process to wait around, which stops >my news from being processed. Whats your cable look like? Your not kludging CD or DTR are you? I had a problem a lot like the one you describe at one time too. I fixed it going to a flat ribbon cable (all 25 lines straight thru). Make sure your modem is set to hangup when DTR goes away. Also, I think when uucico sees MR drop out from under it uucico will exit. Hmm, I just realized you might be using that junk built in modem. Get an external, for sure! -- John "C" Sucilla {ihnp4}!tarkus!jcs Don't let reality stop you....
jr@amanue.UUCP (Jim Rosenberg) (04/11/88)
In article <10800001@fthood> egray@fthood.UUCP writes: >Reference: setgetty getting "lost" > >This is a symptom of editing the /etc/inittab file by hand and not >leaving the space or colon at the begining of the line. I don't think it's quite this simple. In my humble opinion setgetty has a screw or two loose, even if you never touch inittab. Who wouldn't occasionally make the mistake: getoff.sh tty000 instead of what you're supposed to type, which is: getoff.sh 000 When you make this mistake setgetty seems to hang. I frankly can't think of any good excuse for this! (Let's see now, they have six legs, a head, thorax and abdomen, entomologists enjoy them immensely ...) -- Jim Rosenberg CIS: 71515,124 decvax!idis! \ WELL: jer allegra! ---- pitt!amanue!jr BIX: jrosenberg uunet!cmcl2!cadre! /
andrew@teletron.UUCP (Andrew Scott) (04/12/88)
In article <121@slbtoy.UUCP>, slb@slbtoy.UUCP (Sanford L. Barr) writes: > > The transfer works fine... I receive all the incoming news. Then, > when the machines are about to hangup, my machine spawns a "getoff.sh". > "getoff.sh" is a shell script that calles "setgetty" which is supposed > to take the getty off the modem line (why? I don't know - it should be > spawning a new one insead shouldn't it?). Anyhow, the setgetty call hangs > FOREVER - which causes the uucico process to wait around, which stops > my news from being processed. > > Does anyone know what's causing this? Or am I going to have > to try my hand at the AT&T hotline. We have had problems with /usr/bin/setgetty ever since we became a uucp node two years ago. It really was a hassle when setgetty hung on a uucp call on Friday night, and nobody caught it until Monday morning. We would be two days behind in news & mail. Recently I wrote a disassembler that produced UNIX pc assembler source from a COFF object file. Before you ask, no I can't post it. Besides, it's not very polished right now. I disassembled the object file for /usr/bin/setgetty and reverse-compiled the .s file into a C source file. Having looked at lots of .s files to examine the compiler's output made it easier to identify what C statements certain assembler sequences were derived from. Anyway, the gist of this story is that the original code for setgetty is pure crap. It has blatant bugs that even the most novice C programmer would spot. I can't believe that AT&T produced this code. I don't think I should post the reconstructed source, as I don't want to get into any kind of legal hot water. What I *can* mention is what the bug is. There is a function which reads the /etc/inittab file looking for a line of the form " %s" or ":%s", where %s is the device name. If it finds it, the first character is set to a blank or colon, depending on whether we're turning the getty on or off. Now, the code that searches for the line is an infinite loop (sound fishy?) that executes fgets() each time through. If the fgets() fails (i.e. the end of file is reached), the loop is broken. However, the test for fgets() isn't coded very well: char line[132]; FILE *inittab; ... for (;;) { ... fgets(line, 132, inittab); if (line == NULL) break; ... } ... Obviously, the test will never be true. The test should only be true, however, if the line was not found. I don't know why it *wouldn't* be found, if the inittab file was left alone by the user. I tried logging what /etc/inittab looked like when setgetty hung when it was called, but couldn't see anything strange. My solution to the problem was to recompile /usr/bin/setgetty with the above code fragment changed to: if (fgets(line, 132, inittab) == NULL) break; We haven't had any problems since. However, the rest of the program is still poorly written. I would re-write the whole thing, if I had the time. -- Andrew Scott andrew@teletron.uucp or ..alberta!teletron!andrew