austin@spies.sf-bay.org (Glenn Austin) (02/04/91)
I have attempted to use the UUCP which came with A/UX 2.0, and it works fine when logged in as UUCP, but fails (miserably!) when running in the background because UUCICO doesn't correctly handle the options for files transferred. It creates all files as mode 600, and then when UUX attempts to read them (ie. to send mail), it can't access them, and you get returned error messages and nothing gets sent to the recipient! This is a BUG that basically makes A/UX USELESS for UUCP, since you can't set up cron to call, and a feed can't call you! If anybody has access to the source for UUCP, I would really appreciate it if you could send me a copy of it. Adv<Thanks>ance -- ----------------------------------------------------------------------------- | Glenn L. Austin | "Turn too soon, run out of room, | | Auto Racing Enthusiast and | Turn too late, much better fate" | | Macintosh Wizard | - Jim Russell Racing School Instructors |
alexis@panix.uucp (Alexis Rosen) (02/05/91)
austin@spies.sf-bay.org (Glenn Austin) writes: >I have attempted to use the UUCP which came with A/UX 2.0, and it works fine >when logged in as UUCP, but fails (miserably!) when running in the background >because UUCICO doesn't correctly handle the options for files transferred. >It creates all files as mode 600, and then when UUX attempts to read them >(ie. to send mail), it can't access them, and you get returned error messages >and nothing gets sent to the recipient! This is a BUG that basically makes >A/UX USELESS for UUCP, since you can't set up cron to call, and a feed can't >call you! Reasonable complaint. Bad diagnosis. Richard Todd then responds that you've broken something. He's forgotten how he fixed UUCP, though. There are two critical problems with UUCP in A/UX 2.0. The first is the much- mentioned (by me) problem with UUXQT. It dies after 10 jobs or so. You can use the uuxqt.wrap script I posted a few months ago to fix it, or you can use the uuxqt in version 2.0.1, which fixes the problem for good. The other, far nastier (and harder to trace) bug comes from uucico's use of the TZ environment variable. If it doesn't see TZ, it calls a system routine which sets TZ for it. Problem is, that routine is broken. Without TZ, uucico ungracefully dies without useful messages. To fix this, just make sure that both uudemon.hr and uushell (and any polling script you may write) have the following line before they invoke uucico: TZ=`/bin/cat /etc/TIMEZONE` ; export TZ That's it! --- Alexis Rosen Owner/Sysadmin, PANIX Public Access Unix, NY {cmcl2,apple}!panix!alexis
domo@tsa.co.uk (Dominic Dunlop) (02/05/91)
austin@spies.sf-bay.org (Glenn Austin) writes: > 1> I have attempted to use the UUCP which came with A/UX 2.0, and it works fine 1> when logged in as UUCP, but fails (miserably!) when running in the background 1> because UUCICO doesn't correctly handle the options for files transferred. 1> It creates all files as mode 600, and then when UUX attempts to read them 1> (ie. to send mail)... > And in article <1991Feb4.045449.29142@servalan.uucp> rmtodd@servalan.uucp (Richard Todd) expresses the sentiment: 2> [As I don't have a problem, you can't have a a problem or you have done 2> something unspeakably dumb.] Er, lighten up, please. There is indeed a problem with uuxqt, and Glenn seems to be on its track -- even if he has not quite chased it down. The problem is that, when more than <some number less than 20> jobs are queued up for uuxqt to run, uuxqt runs out of file descriptors before it has processed them all. Presumably, there is some loop inside uuxqt which it cycles round for each job, and at the end of which it should be closing all open files -- but doesn't. This bug can present with a number of symptoms. Sometimes it seems that uuxqt itself is failing -- for example, not being able to read files. Sometimes, the child process executed by uuxqt to do the work (typically rmail or rnews) runs out of file descriptors first, because uuxqt has passed it a load of useless open files, and the child does not close them before it tries to open others. Firstly, Apple, can we please have a fix for this long-standing problem? You have, after all, posted fixes for bugs in a (small) number of other utilities to ``A/UX Update and Information Server'' (uucp access on +1 408 559 3066 -- login as aux; annonymous ftp also available on aux.support.apple.com (130.43.6.2)). Secondly, what can Glenn do about it? Well, there has been a fair amount of discussion in this newsgroup -- the archives for which are on the A/UX Update and Information Server. I've found that changing the body of /usr/lib/uucp/uushell -- the shell that gets executed when nuucp logs in -- helps: while :; do sleep 300; /usr/lib/uucp/uuxqt; done & env "TZ=`/bin/cat /etc/TIMEZONE`" /usr/lib/uucp/uucico This works for me because my particular problem is in the processing of large incoming news batches. Having uuxqt run every five minutes while nuucp is logged in means that too few to cause a problem are queued at at any time. It may not work for you, though. I seem to recall that there's also a problem with /bin/rmail. As delivered, it's setuid root. It should be setgid mail instead. If it's setuid root, multiple copies of rmail running simultaneously can overwrite each others' additions to mailboxes because root privilege breaks the locking mechanism that they use serialize their access. The symptom is corrupted mailboxes whenever multiple messages arrive at the same time for the same user. Could be that this classic UniSoft problem is fixed in A/UX 2.0; I don't remember. 2> I've been running UUCP [without problems] on my 2> A/UX machine since April of 1989, have been running news on it since June of 2> 1989, and have been feeding news to other sites and gatewaying mail in and 2> out of central Oklahoma since mid-summer 1990... Well, I'm surprised that you've had no problems. Wish I had your luck (or talent). -- Dominic Dunlop
rmtodd@servalan.uucp (Richard Todd) (02/06/91)
domo@tsa.co.uk (Dominic Dunlop) writes: >Er, lighten up, please. There is indeed a problem with uuxqt, and Glenn Agreed. I was rather rash in my reply, and I publically apologize to Glenn for implying that he was an idiot. I jumped the gun and assumed that because he said he was having permission problems with files, he actually *was*, and I had also forgotten about the two bugs in UUCP which are worked around or fixed on my system. However, his problem is not the (well-known) uuxqt bug, it looks like. For one thing, his original posting mentioned that the problem only occured when uucico/uuxqt wasn't run when he was logged in as uucp; this obviously can't be the problem with uuxqt running out of file descriptors, as this would be independent of the environment that uuxqt is run from. Also, I suspect Glenn would have noticed if it only happened when there were >13 entries in the queue. What the problem is is probably the one where uucico/uuxqt freaks if the TZ environment variable is not set. This causes highly strange things to happen, but not ones which "look" like permission problems. (I just tried it with some news batches waiting for the uuxqt, and got the error message along the lines of "rnews failed (signal 0, exit 2)"). I didn't think of this at first, because a. I didn't remember ever seeing anything that looked like "permission problems", and b. I fixed all my UUCP scripts to include TZ around April '89 and haven't had to think about it since. >down. The problem is that, when more than <some number less than 20> >jobs are queued up for uuxqt to run, uuxqt runs out of file descriptors >before it has processed them all. Presumably, there is some loop >inside uuxqt which it cycles round for each job, and at the end of >which it should be closing all open files -- but doesn't. This bug can Bingo! >present with a number of symptoms. Sometimes it seems that uuxqt >itself is failing -- for example, not being able to read files. >Sometimes, the child process executed by uuxqt to do the work >(typically rmail or rnews) runs out of file descriptors first, because >uuxqt has passed it a load of useless open files, and the child does >not close them before it tries to open others. Yep, that's exactly it. >Firstly, Apple, can we please have a fix for this long-standing problem? >You have, after all, posted fixes for bugs in a (small) number of other >utilities to ``A/UX Update and Information Server'' (uucp access on +1 Apple already knows about this bug; I got a fixed binary in the mail from a guy at Apple after I yelled about it. If enough of you will yell about it, maybe they'll post the fixed binary to aux.support.apple.com. It worked for mkshlib, hey... >This works for me because my particular problem is in the processing of >large incoming news batches. Having uuxqt run every five minutes while >nuucp is logged in means that too few to cause a problem are queued at >at any time. It may not work for you, though. Given a 2400bps newsfeed, and roughly 50K newsbatches, even running uuxqt every 30 minutes seems to be ok. Note that if you, like me, have your system set up to run a poll every 30 minutes, uuxqt will run every 30 minutes whether you want it to or not. >I seem to recall that there's also a problem with /bin/rmail. As >delivered, it's setuid root. It should be setgid mail instead. If it's >setuid root, multiple copies of rmail running simultaneously can >overwrite each others' additions to mailboxes because root privilege >breaks the locking mechanism that they use serialize their access. The >symptom is corrupted mailboxes whenever multiple messages arrive >at the same time for the same user. Could be that this classic UniSoft >problem is fixed in A/UX 2.0; I don't remember. Geez, people still run with /bin/rmail? The first thing I did was toss the entire rmail/sendmail system and install smail 2.5 and deliver. Deliver seems to be a lot more robust in its lock handling, and if you can get everyone on your system to use a real Mail User Agent instead of mailx, you can use one of the kernel locking protocols instead of the ".lock" kludge... >2> I've been running UUCP [without problems] on my >2> A/UX machine since April of 1989, have been running news on it since June of >2> 1989, and have been feeding news to other sites and gatewaying mail in and >2> out of central Oklahoma since mid-summer 1990... >Well, I'm surprised that you've had no problems. Wish I had your luck >(or talent). Well, it wasn't quite as seamless as all that. The TZ problem I spotted right off after an evening's hacking with it (simple detective work--if it works when run from your shell, but not from cron, what could be different between the two? Simple trial-and-error on environment variables did the rest). If you wish to call that "talent", my ego won't mind... As for the uuxqt-heavy-load problem, it simply didn't come up too often until here recently (after a friend of mine downstream from me discovered these wonderful new things called "mailing lists" :-), and by that point I'd already gotten the new uuxqt. So to summarize, it's not that everything was entirely seamless, it's just that millions of my brain cells have died since then. Still, UUCP and News require remarkably little attention; all I have to do is occasionally fiddle the phone number in the L.sys file (alas, guessing which of the 20 modems on my feed site are actually working on any given week is often an adventure...) -- Richard Todd rmtodd@uokmax.ecn.uoknor.edu rmtodd@chinet.chi.il.us rmtodd@servalan.uucp "Try looking in the Yellow Pages under 'Psychotics'." -- Michael Santana
paul@athertn.Atherton.COM (Paul Sander) (02/07/91)
In article <1991Feb5.083527.2506@panix.uucp> alexis@panix.uucp (Alexis Rosen) writes: >austin@spies.sf-bay.org (Glenn Austin) writes: >>I have attempted to use the UUCP which came with A/UX 2.0, and it works fine >>when logged in as UUCP, but fails (miserably!) when running in the background >>because UUCICO doesn't correctly handle the options for files transferred. >>It creates all files as mode 600, and then when UUX attempts to read them >>(ie. to send mail), it can't access them, and you get returned error messages >>and nothing gets sent to the recipient! This is a BUG that basically makes >>A/UX USELESS for UUCP, since you can't set up cron to call, and a feed can't >>call you! [ Alexis' workarounds omitted ] I ran into the TZ problem as well, and discovered the solution independently. I had a long talk with Chuck and Apple's A/UX Technical Answerline this morning, so now they know about the problem. Another problem I ran into was this: After following the advice of Farrow and Thomas (given in their "Unix System V Administration" book), I created a directory called /usr/spool/uucp/X, and found that UUCP would transfer incoming mail, but UUXQT would not spawn rmail. Removing the X directory fixed the problem. -- Paul Sander (408) 734-9822 | "Passwords are like underwear," she said, paul@Atherton.COM | "Both should be changed often." {decwrl,pyramid,sun}!athertn!paul | -- Bennett Falk in "Mom Meets Unix"
liam@cs.qmw.ac.uk (William Roberts;) (02/07/91)
In <1991Feb6.005529.3640@servalan.uucp> rmtodd@servalan.uucp (Richard Todd) writes: >Apple already knows about this bug; I got a fixed binary in the mail from >a guy at Apple after I yelled about it. If enough of you will yell about it, >maybe they'll post the fixed binary to aux.support.apple.com. It worked for >mkshlib, hey... You forget that sound doesn't carry over water... I don't even get the common courtesy of email acknowledgements to bug reports: not even automatically generated acknowledgements. When the machine to which bug-reports should be sent screwed up its mail tables, my bug reports bounced and the best response I got from Cupertino was "we think you should FTP sendmail x.y.z and try again". Perhaps comp.unix.aux should have just a US distribution - much of the rest of A/UX feels that way to me here in England much of the time, and recent postings suggest that things are worse elsewhere in Europe. >... >Geez, people still run with /bin/rmail? The first thing I did was toss the >entire rmail/sendmail system and install smail 2.5 and deliver. Deliver seems >to be a lot more robust in its lock handling, and if you can get everyone on >your system to use a real Mail User Agent instead of mailx, you can use one >of the kernel locking protocols instead of the ".lock" kludge... If anyone is interested, we run MMDF, plus own own local bulletin board system. For netnews we run nn talking to an nntp server. Our most interesting mail-related trick was writing a proper Mac editor for creating mail messages which can be used by mail systems which expect UNIX-like editors: ones that quit when the user has finished creating the message for example... It is a cut-down version of the TESample code from MacDTS, using their A/UX version - not a lot of crazy features but it works fine. -- William Roberts ARPA: liam@cs.qmw.ac.uk Queen Mary & Westfield College UUCP: liam@qmw-cs.UUCP Mile End Road AppleLink: UK0087 LONDON, E1 4NS, UK Tel: 071-975 5250 (Fax: 081-980 6533)