alexis@panix.UUCP (Alexis Rosen) (09/26/90)
I was under the impression that nobody (except for Matthias Urlichs) had anything to say about A/UX. Then I was cleaning out the mail queue last night and I found all sorts of junk, none of it identifiable, except for one large note. (There's at least one way that A/UX 2.0 sucks...) Point is, if you responded to my query (which I posted from a friend's account at acf5.nyu.edu), your mail didn't make it. Fortunately, I think I've dealt a fatal blow to the last of the big UUCP and mail bugs on this system, and I can now receive mail fairly normally via the usual cmcl2!panix!alexis route (not apple!panix!alexis, which is not a good path). So all of you who answered once, please send it again, and I promise my Mac will behave itself this time. :-) In particular, will the person who sent me that long article which mentioned among other things the uuxqt bug (yes, i know _all_ about that one :-( ) contact me? Thanks, Alexis Rosen A/UX Victim (now you know how) cmcl2!panix!alexis alexis@panix.uucp (only if absolutely necessary)
domo@tsa.co.uk (Dominic Dunlop) (09/28/90)
In article <10507@panix.UUCP> alexis@panix.UUCP (Alexis Rosen) writes: > In particular, will the person who sent me that long article which mentioned > among other things the uuxqt bug (yes, i know _all_ about that one :-( ) > contact me? Aha! This would be the bug whereby uuxqt gets bored with processing jobs after a while (around 20 jobs, but bafflingly variable) and either just gives up, or, if it's feeling more playful, fails to exec the commands for the last few batches, and sends mail back to their originators saying ``exit status 2'' or some such. (Looks suspiciously like ``No such file or directory'' -- an outright lie -- to me, since I know that one of the commands in question, rnews, cannot exit with status 2, and I know that it's not being accessed when uuxqt starts to barf.) Anyway, how do you fix this sucker? The bug, which was present in 1.1, seems to be bigger and better in 2.0. (I even looked on Apple's Update and Information server for a fix. No soap...) Altogether now: I want my HDB! -- Dominic Dunlop
rmtodd@servalan.uucp (Richard Todd) (09/29/90)
domo@tsa.co.uk (Dominic Dunlop) writes: >In article <10507@panix.UUCP> alexis@panix.UUCP (Alexis Rosen) writes: >> In particular, will the person who sent me that long article which mentioned >> among other things the uuxqt bug (yes, i know _all_ about that one :-( ) That would be me, I think. I'll dig out that email and send it again. Alexis, if you don't get it this time, let me know and I'll post it; it's probably of interest to the A/UX community in general. >Aha! This would be the bug whereby uuxqt gets bored with processing >jobs after a while (around 20 jobs, but bafflingly variable) and either >just gives up, or, if it's feeling more playful, fails to exec the >commands for the last few batches, and sends mail back to their >originators saying ``exit status 2'' or some such. (Looks suspiciously >like ``No such file or directory'' -- an outright lie -- to me, since I >know that one of the commands in question, rnews, cannot exit with >status 2, and I know that it's not being accessed when uuxqt starts to >barf.) The problem is that in uuxqt's main loop, where it processes each file, it forgets to close one of the files. Eventually it runs out of file handles, can't open the work files, and aborts. This in itself isn't too bad (it just aborts and leaves the work files around for the next batch), but when it's just one or two XQTs away from disaster, hence it's only got 1 or 2 free file handles; when rnews is forked off and runs, it only has 1 or 2 file handles, and when it tries to do all those `spacefor`'s and stuff (which require opening pipes, etc.) rnews fails in all sorts of entertaining ways (usually coming to the erroneous conclusion that the disk is out of space.) I gather this bug is in a few other UUCP implementations besides Apple's; at least, last time somebody asked on news.software.b why all his news batches were being eaten on A/UX, Henry Spencer basically said, "Oh, your uuxqt has the bug where ..." >Anyway, how do you fix this sucker? The bug, which was present in 1.1, >seems to be bigger and better in 2.0. (I even looked on Apple's Update >and Information server for a fix. No soap...) First, you rob a bank. Then, you use the $75,000 you got from robbing the bank to buy an AT&T source licence. :-). Seriously, *you* probably can't fix the bug. You can, however, come up with a workaround of sorts. The problem is that rnews freaks out when it can't open files and pipes because of too few file descriptors. A workaround is to move /bin/rnews to /bin/rnews.real and compile the following and put in as /bin/rnews. -------------------------Cut here---------------------------- /* ** Program to get around uuxqt's problem in not closing file descriptors-- ** this is a front end to rnews that ensures that all fds from 3 up are ** closed before the real rnews is executed. */ main() { int n=getdtablesize(); int i; for (i = 3 ; i < n ; ++i) close(i); execl("/bin/sh","sh","/bin/rnews.real",(char *)0); } -------------------------Cut here------------------------------ Of course, when uuxqt itself runs out of file descriptors, it will fail, but it seems to fail "cleanly", i.e. just leaving the remaining work files around for the next uuxqt run. >Altogether now: I want my HDB! Well, I'd settle for just a fixed version of uuxqt; having grown accustomed to old-UUCP, I really don't want to start learning about HDB's bugs.... -- Richard Todd rmtodd@uokmax.ecn.uoknor.edu rmtodd@chinet.chi.il.us rmtodd@servalan.uucp Motorola Skates On Intel's Head!