Bug 62394 - uucico occassionally fails to call out
uucico occassionally fails to call out
Status: CLOSED DUPLICATE of bug 63468
Product: Red Hat Linux
Classification: Retired
Component: uucp (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jens Petersen
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2002-03-30 21:56 EST by greg hosler
Modified: 2007-04-18 12:41 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-08-05 00:40:21 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
sample program to demonstrate problem (336 bytes, text/plain)
2002-04-01 08:49 EST, greg hosler
no flags Details

  None (edit)
Description greg hosler 2002-03-30 21:56:00 EST
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:

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().


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.
Comment 1 greg hosler 2002-03-30 22:00:00 EST
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).
Comment 2 greg hosler 2002-03-31 09:02:47 EST
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.
Comment 3 greg hosler 2002-03-31 18:34:08 EST
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).
Comment 4 greg hosler 2002-04-01 08:48:17 EST
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
Comment 5 greg hosler 2002-04-01 08:49:22 EST
Created attachment 51644 [details]
sample program to demonstrate problem
Comment 6 greg hosler 2002-04-06 02:06:05 EST
Problem still exists in Skipjack-2 (aka Hampton beta 4)
Comment 7 greg hosler 2002-08-05 11:16:17 EDT
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 ***

Note You need to log in before you can comment on or make changes to this bug.