Newsgroups: comp.unix.aux
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!uupsi!cmcl2!panix!alexis
From: alexis@panix.uucp (Alexis Rosen)
Subject: Re: TZ/rmail problems again
Message-ID: <1991Apr4.093613.24871@panix.uucp>
Date: Thu, 4 Apr 91 09:36:13 GMT
References: <1991Mar27.033217.452@deadzone.uucp> <1991Apr1.230647.14919@intacc.uucp>
Organization: PANIX - Public Access Unix Systems of NY

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