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): How reproducible: Sometimes 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(). 2. 3. Additional info: 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.
Additional information. 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 lockdev/glibc/kernel related. 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 within lockdev. 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 ***