Recommendation: don't run uuhosts in your news sys file

Brian Reid reid at Glacier.ARPA
Mon Aug 12 06:47:17 AEST 1985


John Quarterman kindly posted "uuhosts" recently, and like most of the SA's
I know, I installed it. Since then I have experienced two severe total
lockups of the entire news/mail system, both of which were traceable to
uuhosts; furthermore, by killing uuhosts I was able to unlock things. 

I think that the basic problem is that when you put a line like this in your
sys file:
maps:mod.map.uucp:B:uuhosts -x
that the "uuhosts" program is run in a fork hierarchy approximately like
this (I haven't checked to see if inews forks uuhosts directly or if some
other agent is involved; the principle is the same regardless):
	uucico -- uuxqt -- rnews -- inews -- uuhosts
The kicker is that uhosts can take a couple of hours to run on a heavily
loaded system. In particular, for the recent distribution of eur.*,
uuhosts took about 4 wall clock hours to run. This means that while uuhosts
was running for those 4 hours, inews was waiting for it to finish. While
inews was waiting for it to finish, the news system was locked up. While
uuxqt was waiting for rnews to wait for inews to finish, the LCK.XQT file
was set and no other uucp traffic was moving.

For some reason that I still can't quite figure out, this uucp-world jamup
managed to propagate over to the sendmail--/usr/spool/mqueue world, and
lock THAT up for 4 hours. After 4 hours of being locked up, some process
abandoned ship somewhere, and I had to manually restart sendmail to get the
mail going again (I have seen this failure in sendmail -q1h before; running
sendmail -q from crontab once per hour works better).

What I recommend that people do is to copy Rick Adams' "turning off rnews"
hack, and to capture the maps by calling a shell script that saves its
standard input in /usr/spool/news/uucpmaps.$$, where $$ is the pid, and then
have some crontab-driven thing that comes around later and runs uuhosts -x
over all of those files. I just installed this on Glacier, and it's too soon
to report success, but it has to work better than running it directly from
the sys file.
-- 
	Brian Reid	decwrl!glacier!reid
	Stanford	reid at SU-Glacier.ARPA



More information about the Comp.sources.bugs mailing list