marcelo@deadzone.uucp (Marcelo Gallardo) (03/27/91)
Help I've lost my TimeZone, and I can't get mail! Once again this wonderful bug has found it's way into deadzone, this time really bothering me and my mail feed. I've checked everything that uucp uses to call or accept logins, and they all have the TZ set prior to executing anything, yet I still get the following message somtimes... "TZ=/bin/cat rmail marcelo" Is there anything else I can check? I've looked through everything I could think of, installed Alexis' scripts (but they are for a different problem). The biggest problem is that it's not consistent. I could be running for days without ever seeing that "pain-in-the-rear" message, and other times I can be running for just a few minutes and it starts up. Any ideas or am I helplessly left in a "Time Warp"? -- Marcelo Gallardo marcelo%deadzone@princeton.edu Test and Evaluation Specialist ...!princeton!deadzone!marcelo Princeton University marcelo@sparcwood.princeton.edu Advanced Technologies and Applications (609) 258-5661
unger@mitem.uucp (Tom Unger) (03/29/91)
In article <1991Mar27.033217.452@deadzone.uucp> marcelo@deadzone.uucp (Marcelo Gallardo) writes: > > Help I've lost my TimeZone, and I can't get mail! > > I've checked everything that uucp uses to call or accept logins, > and they all have the TZ set prior to executing anything, yet I > still get the following message somtimes... > > "TZ=/bin/cat rmail marcelo" I fixed this when I first got the system and have not had a problem since. If memory serves, which it may not, it was a quoting problem in the file uushell. The last line in mine looks like: env "TZ=`/bin/cat /etc/TIMEZONE`" /usr/lib/uucp/uucico If your's is quoted differently that may be the problem. If your's is quoted the same then my memory failed and I have no idea what your bug is. Tom Unger MITEM.
mann@intacc.uucp (Jeff Mann) (04/02/91)
In article <1991Mar27.033217.452@deadzone.uucp> marcelo@deadzone.uucp (Marcelo Gallardo) writes: > I've checked everything that uucp uses to call or accept logins, > and they all have the TZ set prior to executing anything, yet I > still get the following message somtimes... > > "TZ=/bin/cat rmail marcelo" > > Is there anything else I can check? I've looked through > everything I could think of, installed Alexis' scripts (but they > are for a different problem). > > The biggest problem is that it's not consistent. I could be > running for days without ever seeing that "pain-in-the-rear" > message, and other times I can be running for just a few minutes > and it starts up. I have also experienced this mysterious problem, under the same circumstances. I have no Idea what causes it or what the solution is. The message you describe appears in a mail message going back to the sender, and MAIL FAIL appears in the LOGFILE. Let me know if you figure it out!! =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Jeff Mann Inter/Access Artists' Computer Centre, Toronto [416] 535-8601 | | intacc!mann@cs.toronto.edu Matrix Artists' BBS: [416] 535-7598 2400 8N1 | | ...uunet!mnetor!intacc!mann mann@intacc.uucp [416] 535-1443 Telebit 8N1 | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
alexis@panix.uucp (Alexis Rosen) (04/04/91)
In article <1991Apr1.230647.14919@intacc.uucp> mann@intacc.uucp (Jeff Mann) writes: >In article <1991Mar27.033217.452@deadzone.uucp> marcelo@deadzone.uucp (Marcelo Gallardo) writes: >> I've checked everything that uucp uses to call or accept logins, >> and they all have the TZ set prior to executing anything, yet I >> still get the following message somtimes... >> >> "TZ=/bin/cat rmail marcelo" >> >> Is there anything else I can check? I've looked through >> everything I could think of, installed Alexis' scripts (but they >> are for a different problem). >> >> The biggest problem is that it's not consistent. I could be >> running for days without ever seeing that "pain-in-the-rear" >> message, and other times I can be running for just a few minutes >> and it starts up. > >I have also experienced this mysterious problem, under the same >circumstances. I have no Idea what causes it or what the solution >is. The message you describe appears in a mail message going back >to the sender, and MAIL FAIL appears in the LOGFILE. Let me know >if you figure it out!! Reading over this (and several other news and mail messages) it occurs to me that I may have given people a false impression. It is *NOT* uucico which causes this problem. The symptoms of a bad uucico are failed connections. The cause of this is a *uuxqt* without TZ set properly. Now most of the time, uuxqt is only invoked by uucico, so if you set TZ correctly for uucico you'll automatically get it right for uuxqt as well. If you run uuxqt by hand, it will also work OK, because TZ is always defined in user environments. The big "but" is that if you invoke uuxqt from cron, which is in some cases a good strategy, you MUST provide TZ in its environment. The easiest way to do that is to say something like: TZ=`/bin/cat /etc/TIMEZONE` ; export TZ ; /usr/lib/uucp/uuxqt in your crontab instead of just /usr/lib/uucp/uuxqt. If you use my wrapper (and you must, if you're using A/UX 2.0.0, or else something similar), this will also do the job. BTW, in the scripts I posted a couple of weeks ago, I didn't post one thing I'd done because I still considered it experimental, but it seems to work beautifully, so try this... in both those scripts, I've got a line which says something like "/usr/lib/uucp/uucico some-args & uuproc=$! ; wait". Try replacing the "wait" with a loop that looks like this: while kill -0 $uuproc 2>/dev/null ; do /usr/lib/uucp/uuxqt ; sleep 90 done NOTE- this is only useful in 2.0.1, or if you're using the fixed uuxqt binary from apple with 2.0.0. It has two beneficial effects: First, it distributes incoming mail and news in a more timely fashion than deos one big uuxqt at the end of the job, and second, it prevents huge accumulations of simultaneous mail jobs to the same user that produce those nasty failed mail-lock problems. Load is not significantly impacted. In fact, it can improve, because there will always be fewer jobs at any given time with this technique. This scheme eliminates the need for cron-ing uuxqt, which would indirectly eliminate the problem quoted above, if that were the cause. Also, if you're using a low-speed modem (slower than V.32 or telebit/PEP), you might want to change that sleep to 300 or 400. --- Alexis Rosen Owner/Sysadmin, PANIX Public Access Unix, NY {cmcl2,apple}!panix!alexis
mann@intacc.uucp (Jeff Mann) (04/14/91)
In article <1991Apr4.093613.24871@panix.uucp> alexis@panix.uucp (Alexis Rosen) writes: >In article <1991Apr1.230647.14919@intacc.uucp> mann@intacc.uucp (Jeff Mann) writes: >>In article <1991Mar27.033217.452@deadzone.uucp> marcelo@deadzone.uucp (Marcelo Gallardo) writes: >>> I've checked everything that uucp uses to call or accept logins, >>> and they all have the TZ set prior to executing anything, yet I >>> still get the following message somtimes... >>> >>> "TZ=/bin/cat rmail marcelo" >> >>I have also experienced this mysterious problem, under the same >>circumstances. I have no Idea what causes it or what the solution >>is. The message you describe appears in a mail message going back >>to the sender, and MAIL FAIL appears in the LOGFILE. Let me know >>if you figure it out!! > >The cause of this is a *uuxqt* without TZ set properly. Now most of the time, >uuxqt is only invoked by uucico, so if you set TZ correctly for uucico you'll >automatically get it right for uuxqt as well. If you run uuxqt by hand, it >will also work OK, because TZ is always defined in user environments. > >The big "but" is that if you invoke uuxqt from cron, which is in some cases >a good strategy, you MUST provide TZ in its environment. The easiest way to >do that is to say something like: >TZ=`/bin/cat /etc/TIMEZONE` ; export TZ ; /usr/lib/uucp/uuxqt >in your crontab instead of just /usr/lib/uucp/uuxqt. > >If you use my wrapper (and you must, if you're using A/UX 2.0.0, or else >something similar), this will also do the job. Sorry... that's not it. :-( I do use your wrapper, and I don't run uuxqt from cron. It's only ever run by uucico. Take a look at the error message: From uucp Sat Apr 13 10:59:55 1991 remote from intacc Received: by intacc (5.61/SMI-3.2) id AA16690; Sat, 13 Apr 91 10:59:55 PDT Date: Sat, 13 Apr 91 10:59:55 PDT From: intacc!uucp (0000-UUCP Admin(0000)) Message-Id: <9104131759.AA16690@intacc> To: yunexus!root Mail failed (PATH=/bin:/usr/bin LOGNAME=uucp TZ=`/bin/cat rmail uucp ). Letter returned to sender. ...it looks like some kind of string/memory overrun in uuxqt. What should be TZ=`/bin/cat /etc/timezone` rmail uucp is truncated to: TZ=`/bin/cat rmail uucp Obviously, `/bin/cat rmail` is a Bad Thing! This only happens to me with mail from one particular system (yunexus). One thing I noticed was that they log in with a nine-character name: uuyunexus. I can't really think how that would cause this, but it's the only thing I can think of that's different from the other uucp callers. I have just changed their login to an eight-character name, so we'll soon see... =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Jeff Mann Inter/Access Artists' Computer Centre, Toronto [416] 535-8601 | | intacc!mann@cs.toronto.edu Matrix Artists' BBS: [416] 535-7598 2400 8N1 | | ...uunet!mnetor!intacc!mann mann@intacc.uucp [416] 535-1443 Telebit 8N1 | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
alexis@panix.uucp (Alexis Rosen) (04/17/91)
urlichs@smurf.sub.org (Matthias Urlichs) writes: [quoting me about uuxqt] >< >The cause of this is a *uuxqt* without TZ set properly. > >I would like to know why anybody would even _need_ TZ defined as anything. >The C library takes care of the whole mess automatically by looking at the >appropriate files in /etc/zoneinfo! > >Obviously the UUCP (and probably rmail also) code needs some serious bashing >to throw out every scrap of code that deals with time, to be replaced with >calls to the C library. Somebody at Apple should do that. Now. Well, in fact uuxqt and uucico et al. are _not_ broken. It seems that, in fact, the C library is broken. Apple knew about this and declined to fix it in 2.0.1, but I hear that it definitely will be fixed next time around. (This is all from discussions with Apple people who looked into the problem.) >I'm somewhat unhappy about the current situation, not because it causes >problems for me but because it generates the strong impression that here is a >very unnecessary and painful problem with a very obvious and simple solution, >only the people in charge don't seem to be doing anything about it. >(If that impression is totally wrong, so much the better; but the outside >world seems to get a different picture.) Your impression is correct. They made a decision without, I think, proper regard for the (relatively small) investment of time it would take to deal with the problem. They believed that few people were affected by this and chose to put their energies elsewheres. While I respect the need for prioritizing I feel that this was a serious mistake. Clearly many of us are affected by it. (Whether there are enough of us to warrnat fixing it can only be decided by Apple, of course.) ...But cheer up. As I said, they have finally seen the light. I expect this to be fixed for good in the next version. For the few who continue to have problems, of course, this is small consolation. >NB: If I could distribute the binaries I compiled from BSD UUCP, the problem > would go away, but it seems that the legal matters involved prevent me > from doing that. Sorry. HDB, you can't distribute. But BSD UUCP binaries should be fine. All A/UX users have binary licenses from AT&T so what's the problem? Surely there's no difficulty in releasing the stuff that's BSD... --- Alexis Rosen Owner/Sysadmin, PANIX Public Access Unix, NY {cmcl2,apple}!panix!alexis
urlichs@smurf.sub.org (Matthias Urlichs) (04/18/91)
In comp.unix.aux, article <1991Apr17.054945.21653@panix.uucp>, alexis@panix.uucp (Alexis Rosen) writes: < urlichs@smurf.sub.org (Matthias Urlichs) writes: [quoting me about uuxqt] < >< >The cause of this is a *uuxqt* without TZ set properly. < > < >I would like to know why anybody would even _need_ TZ defined as anything. < >The C library takes care of the whole mess automatically by looking at the < >appropriate files in /etc/zoneinfo! < < Well, in fact uuxqt and uucico et al. are _not_ broken. It seems that, in < fact, the C library is broken. Apple knew about this and declined to fix it < in 2.0.1, but I hear that it definitely will be fixed next time around. < (This is all from discussions with Apple people who looked into the problem.) < Why, then, does this test program work as expected: #define _POSIX_SOURCE #include <sys/types.h> #include <time.h> #include <stdio.h> main() { struct tm *t; time_t tim; time(&tim); t = localtime(&tim); t->tm_year += 1900; printf("%02d.%02d.%04d %s\n", t->tm_mday, t->tm_mon+1, t->tm_year, tzname[t->tm_isdst]); } ??? (TZ is unset. If it's empty, I get GMT which also works as expected.) < >NB: If I could distribute the binaries I compiled from BSD UUCP, the problem < > would go away, but it seems that the legal matters involved prevent me < > from doing that. Sorry. < < HDB, you can't distribute. But BSD UUCP binaries should be fine. All A/UX < users have binary licenses from AT&T so what's the problem? Surely there's < no difficulty in releasing the stuff that's BSD... < Well, the above impression (in a nutshell) was what I got when asking one of the local people. If asking the local who's responsible for our licensing stuff gets me a better answer, I'll ask him instead, no problem. ;-) -- Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de /(o\ Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49-721-621127(0700-2330) \o)/