mel@fleet.UUCP (mel) (01/02/90)
I believe I found the source of the problem in SCO Xenix 2.3.2. IT's A BUG IN SCO's CODE!!! I've been experiencing failures in the uucp mail system as previously posted. As per SCO's documentation I have setup the following entry in my "root" cron file. 39,9 * * * * /bin/su uucp -c "/usr/lib/uucp/uudemon.hour" >/dev/null 2>&1 This runs the following shell script; ------------------------------------------------------------------------- $ $ more uudemon.hour : # @(#) uudemon.hour 1.1 88/11/16 # # Copyright (C) The Santa Cruz Operation, 1988. # This Module contains Proprietary Information of # The Santa Cruz Operation, Microsoft Corporation # and AT&T, and should be treated as Confidential. # /usr/lib/uucp/uusched & /usr/lib/uucp/uuxqt & ------------------------------------------------------------------------- As you can see two "programs" are run from this scrip. When I ran the "uusched" from Xenix 2.3.2 in foreground I got the following result; # ./uusched2.3.2 Memory fault THIS DOES NOT HAPPEN WHEN I RUN THE OLD XENIX 2.3.1's "uusched" !! And the two files are different as can be seen from the following directory info comparison. 2.3.1 ver-> ---s--x--x 1 uucp uucp 33724 Dec 30 18:13 uusched 2.3.2 ver-> ---s--x--x 1 uucp uucp 40200 Nov 17 1988 uusched Also left behind in "/usr/spool/uucp" when 2.3.2's "uusched" is the following lock file. -r--r--r-- 1 uucp uucp 11 Jan 1 15:55 LCK.S.0 Since I replaced 2.3.2's "uusched" with the one from "2.3.1" I've had no problem. I sure that SCO attempted to improve this program hence its increase in size BUT looks like they've introduced some bug(s) in the 2.3.2 version. I've done memory checks and can find no problem there.. And judging from growing reports on the net I'm not alone with this problem. Hope SCO reads this and can respond with a fix or work-a-round. Mel Shear, Fleet Parts & Equipment; Harahan, LA. uucp: rex!fleet!mel bitnet: mel%fleet@REX.CS.TULANE.EDU internet: mel%fleet@rex.cs.tulane.edu
kabra437@pallas.UUCP (Ken Abrams) (01/05/90)
In article <58@fleet.UUCP> mel@fleet.UUCP (mel) writes: >I believe I found the source of the problem in SCO Xenix 2.3.2. >IT's A BUG IN SCO's CODE!!! [details deleted] >And judging from growing reports on the net I'm not alone >Hope SCO reads this and can respond with a fix or work-a-round. > Looks you have gone to a fair amount of trouble tracking down this problem. I hope that you will communicate your findings directly to SCO instead of counting on them seeing your excellent summary on the net. It is definitely nice of you to pass this information along; would be a shame if the people who REALLY need to know it were to miss out (the folks at SCO, that is). Keep up the good work.
bob@rel.mi.org (Bob Leffler) (01/05/90)
In article <58@fleet.UUCP>, mel@fleet.UUCP (mel) writes: > I believe I found the source of the problem in SCO Xenix 2.3.2. > directory info comparison. > > 2.3.1 ver-> ---s--x--x 1 uucp uucp 33724 Dec 30 18:13 uusched > 2.3.2 ver-> ---s--x--x 1 uucp uucp 40200 Nov 17 1988 uusched > I'm assuming that this is related to the 386 only. I have 2.3.2 Xenix/286 and I haven't experienced the core dumps yet. Since the 286 binary is quite smaller, than those listed above. ---s--x--x 1 uucp uucp 26336 May 8 1989 uusched bob -- Bob Leffler - Electronic Data Systems, GM Staffs, Office Systems Support Center 3044 West Grand Blvd., Room 11-101, Detroit, MI 48202 (313) 556-4474 bob@rel.mi.org or {uunet!edsews, rutgers, sharkey}!rel!bob Opinions expressed may not be those of my employer.
caf@omen.UUCP (WA7KGX) (01/06/90)
Better bet is: don't use uusched, it may not do what you wish. I run the following shell script quite often (fequency depends on hour of the day) with output redirected to a spare Multiscreen: date "+$0: %H%M %D" if test -f /usr/spool/uucp/LCK..tty1F then exit 0 fi if test -f /usr/spool/uucp/LCK..tty1f then exit 0 fi cd /u/spool/yam PHONES=/u/caf/bin/phones.t export PHONES mon=/dev/tty08 ulimit 20000 umask 000 if lc *.xx* >/dev/null 2>&1 then for i in *.xx* do chown caf $i su caf -c "yam source $i" 2>&1 | tee $mon >>/tmp/.ttyout done fi if egrep 'FAILED' /usr/spool/uucp/.Status/percy then (mkdir /usr/spool/uucp/percy; touch /usr/spool/uucp/percy/C.percyN0000) >/dev/null 2>&1 rm -f /usr/spool/uucp/.Status/percy fi cd /usr/spool/uucp /bin/su uucp -c "/usr/lib/uucp/uudemon.hour" > /usr/spool/uucp/ulog 2>&1 exit 0 The beginning of the script calls Professional-YAM to tour CompuServe, BIX, GEnie, bulletin boards, etc. under control of files in the /u/spool/yam directory. The following crontab lines control one such polling: 0 5 * * * umask 0; echo " call cbbs-r" > /u/spool/yam/cbbs.xx 0 11 * * * rm -f /u/spool/yam/cbbs.xx And then the above script removes a failed .Status file for site percy if one exists. UUCP to percy (news feed) dies alot and there's no point waiting an hour to try again. A crontab entry: 0 2,3,5,7,19 * * * /bin/su uucp -c "(mkdir /usr/spool/uucp/percy; touch /usr/spool/uucp/percy/C.percyN0000) >/dev/null 2>&1" 50 9,19 * * * rm -f /usr/spool/uucp/percy/C.percyN0000 The end result of this is, my system calls percy 5 times a day and only 5 times a day. It "attack dials" (once every 5 or 20 minutes) as necessary to get those 5 connections. "Most of these vi experts know what they do from studying the source code, not by reading the manual." -- Ray Swartz Chuck Forsberg WA7KGX ...!tektronix!reed!omen!caf Author of YMODEM, ZMODEM, Professional-YAM, ZCOMM, and DSZ Omen Technology Inc "The High Reliability Software" 17505-V NW Sauvie IS RD Portland OR 97231 503-621-3406 TeleGodzilla:621-3746 FAX:621-3735 CIS:70007,2304 Genie:CAF
erc@khijol.UUCP (Edwin R. Carp) (01/06/90)
I have the same problem. Here's my workaround. "uustatus" is a program that I posted to alt.sources a while back. If anyone wants it, send the following to archive-server@khijol: send uustatus.shar Here's what uudemon.hour looks like: /usr/local/bin/uustatus -u /usr/lib/uucp/uuxqt -- Ed Carp N7EKG/5 (28.3-28.5) uunet!cs.utexas.edu!khijol!erc Austin, Texas (512) 832-5884 "Good tea. Nice house." - Worf *** Did you know that Barbie Benton PLAYS THE PIANO?? Quite well, too! ***
erc@khijol.UUCP (Edwin R. Carp) (01/06/90)
I have the same problem. Here's my workaround. "uustatus" is a program that I posted to alt.sources a while back. If anyone wants it, send the following to archive-server@khijol: send shars/uustatus.shar Here's what uudemon.hour looks like: /usr/local/bin/uustatus -u /usr/lib/uucp/uuxqt -- Ed Carp N7EKG/5 (28.3-28.5) uunet!cs.utexas.edu!khijol!erc Austin, Texas (512) 832-5884 "Good tea. Nice house." - Worf *** Did you know that Barbie Benton PLAYS THE PIANO?? Quite well, too! ***
bblue@crash.cts.com (Bill Blue) (01/06/90)
In article <3@omen.UUCP> caf@omen.UUCP (WA7KGX) writes: >Better bet is: don't use uusched, it may not do what you wish. >I run the following shell script quite often (fequency depends >on hour of the day) with output redirected to a spare Multiscreen: Wasn't this whole business of the broken 2.3.2 uusched resolved a long time ago? The solution is simple, just use your 2.3.1 uusched, 2.3.2's is broken. I'm sorta surprised that none of those who were involved in the original discovery have commented before now. --Bill