From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020401 Description of problem: the ttylock/ttyunlock routines of baudboy.h will incorrectly return an error occassionally. Specifically, if the fork/execv, and the subsequent execution of lockdev happen, and lockdev exits _BEFORE_ the waitpid call of baudboy's "doit()", then the waitpid() will see a -1 return, with an error code of ECHILD. The end result is that the caller (that called ttylock/ttyunlock) will see a false error return when infact the ttylock/ttyunlock succeeded. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 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 Actual Results: generally several times out of the 10,000 loop lockdev will finish and exit BEFORE the waitpid is started, and then waitpid will see an error of -1 (with errno of ECHILD). Expected Results: false errors should not occur Additional info:
Created attachment 53787 [details] sample program which demonstrates failure
(assigned it to JBJ as he was the one adding baudboy)
Created attachment 54324 [details] new SRPM with patch
The problem is that under some scheduling conditions, it is possible for the fork/execv and exec'd process to run to completion before the fork() returns. Whenever that happens, the return status is lost (because the installed signal handler sets SIGCHLD to SIG_IGN). The attached fix corrects ths problem by installing a signal handler with the intent purpose of catching the return status BEFORE the fork(), and then waits around for the return status (which might be ready when the fork completes).
Note: this is the same problem as 62394, but I couldn't get anyone to look at 62394 so I refiled it under lockdev (after tracking the bug to lockdev).
Your signal patch should be in lockdev-1.0.0-19. Thanks again for doing the heavy lifting.
*** Bug 62394 has been marked as a duplicate of this bug. ***