jfh@rpp386.Dallas.TX.US (The Beach Bum) (09/07/88)
I'm not certain this is limited to SCO Xenix, hence the cross-post.
If there are UUCP files in /usr/spool/uucp which are not readable
by uucico, uucico will hang in a loop continuously re-reading the
spool directory scanning for work.
For example, say the file C.glorpA1234 exists in the spool directory and
is not readable by uucico. If uucico is currently conversing with glorp,
then whenever uucico enters MASTER mode it will search for work for
glorp. It will fail to open C.glorpA1234, scan for more work, find
C.glorpA1234, fail to open it and so on.
Changing the ownership of all UUCP files in the spool directory to the
owner of uucico will correct the problem. Uucico does not report any
errors while this is going on. It just hangs in this stupid loop ...
--
John F. Haugh II (jfh@rpp386.Dallas.TX.US) HASA, "S" Division
"If the code and the comments disagree, then both are probably wrong."
-- Norm Schryerjim@fsc2086.UUCP (Jim O'Connor) (09/09/88)
In article <6293@rpp386.Dallas.TX.US>, jfh@rpp386.Dallas.TX.US (The Beach Bum) writes: > I'm not certain this is limited to SCO Xenix, hence the cross-post. > > If there are UUCP files in /usr/spool/uucp which are not readable > by uucico, uucico will hang in a loop continuously re-reading the > spool directory scanning for work. > > Changing the ownership of all UUCP files in the spool directory to the > owner of uucico will correct the problem. . . . The programs "uucp" and "uux" should be setuid to your uucp user (usually uucp). This way, whenever uucp or uux create a work file in /usr/spool/uucp it will be assured to have the owner id of the uucicio process (which should also be setuid uucp). Just run # cd /usr/bin # chown uucp uucp uux # chmod 4711 uucp uux # cd /usr/lib/uucp # chown uucp uucico # chmod 4711 uucico To make sure those files are all in agreement.