Red Hat Bugzilla – Bug 62394
uucico occassionally fails to call out
Last modified: 2007-04-18 12:41:29 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020314
Description of problem:
This might be a lockdev bug, this might be a uucp bug, this might be a glibc bug.
I have a crontab entry that calls up my uucp server half hourly. About 5% of the
time, I get the failure:
ERROR: All matching ports in use
At the time I get this, the callout port is definately not being used. This
problem has been in existance since the switchover to lockdev, late in engima
(7.2 beta cycle).
I recently got around to putting some debug code into uucp. Inside
log.c : fsserial_lockfile, I put a ulog to display the error # returned (from
ttylock). The error return is "-10", which is
ELOOP - I looked at ttylock (inside baudboy.h, of lockdev-devel) and
this is the return code from an execv call. Looking at the execv call, a return
of ELOOP makes no sense.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. set up a uucp call out. you really don't need a valid uucp server, don't even
really need a valid phone #. The only thing you need is a phone number to try.
about 5% of the time, instead of getting a usual timeout error, you will get the
"All matching ports in use" error, which is due to a
-10 return from ttylock().
if you can give me some instructions to link uucp against a debug version of
glibc, I'll be happy to run valgrind on this. I'm really suspecting an
uninitialized variable, and valgrind is pretty good at finding these.
The ttylock() call to lockdev definately DOES happen. I put some syslogs into
lockdev, to print out the call parameters, and the return value. At the times
of failure, lockdev definately gets forked, definately runs successfully, and
definately returns a success return (i.e. a zero).
correction: error # -10 is not be ELOOP (I got confused by the list in
baudboy.h), error #-10 is ECHILD (No child processes) - not sure if the ECHILD
return value is from the forced return, or from errno. Will investigate this week.
The waitpid occassionally returns -1, with errno set to 10 - checking the
waitpid man page, I note language about threads (which I do not think
applies in this case), but it also occured to me to mention that my systel
is dual cpu (which also should not matter, but possibly does).
This bug appears not to b euucp/uucico related, but instead appears to be
attached is a simple c program which loops and does ttylock() / ttyunlock()
will occassionally fail.
to compile: cc -o foo foo.c
then, as root: chown uucp.uucp foo; chmod 6555 foo
then as normal user: ./foo
Created attachment 51644 [details]
sample program to demonstrate problem
Problem still exists in Skipjack-2 (aka Hampton beta 4)
The problem (after investigation) was due to an error in the signal handling
The lockdev bug was reported as #63468, and I believe has been fixed (though I
have not verified the fix yet).
This bug is a dup of 63468.
*** This bug has been marked as a duplicate of 63468 ***