Bug 221742

Summary: fcntl64 on BAD File descriptors - 1024 times while starting haldaemon!!
Product: [Fedora] Fedora Reporter: Parag Warudkar <parag.lkml>
Component: halAssignee: David Zeuthen <davidz>
Status: CLOSED UPSTREAM QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 6CC: mclasen
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-03-26 22:49:30 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
path.patch none

Description Parag Warudkar 2007-01-07 03:41:42 UTC 
Description of problem:

It seems like when I start haldaemon service using /etc/init.d/haldaemon start,
we do 
getrlimit(....) to get maximum open file descriptors = 1024. And then go closing
them all one by one as visible from the strace output below -

[pid  4224] fcntl64(971, F_SETFD, FD_CLOEXEC) = -1 EBADF (Bad file descriptor)
[pid  4224] fcntl64(972, F_SETFD, FD_CLOEXEC) = -1 EBADF (Bad file descriptor)
[pid  4224] fcntl64(973, F_SETFD, FD_CLOEXEC) = -1 EBADF (Bad file descriptor)
 :
 :
 :
all the way up to 1024. 

It seems totally useless to me as virtually all fcntl64 calls result in an EBADF
meaning the file descriptor most likely wasn't open at all.

In cases where I set the limit of open file descriptors to say 16384 this
fcntl64 would be repeated that many times!

The calls most certainly seem to be coming from the initscripts some how - if I
strace hald it doesn't show these calls. (I even verified in the hald sources
that it is not doing any of this.)

Not sure where exactly in the init scripts they are coming from though.
 

Version-Release number of selected component (if applicable):
initscripts-8.45.7-1

How reproducible:
Always

Steps to Reproduce:
1. strace -f /etc/init.d/haldaemon start
2. Observe output for fcntl64 calls resulting in EBADF
3.
  
Actual results:
Does fcntl64 1024 times on bad file descriptors

Expected results:
Should only do fcntl64 on valid file descriptors, without cycling through the
maximum allowed file descriptors

Additional info:
Comment 1 Parag Warudkar 2007-01-08 18:31:51 UTC 
I don't think it's a HAL bug - As I stated earlier hald when started
independently does not exhibit this problem. I have checked the HAL sources (FC6
SRPM) and there are no calls to getrlimit or fcntl64 anywhere in there. (Problem
only happens when hald is started as service.)
Comment 2 Parag Warudkar 2007-01-13 01:38:14 UTC 
Scratch my last comment - I just repeated strace on hald this time with -f and
it shows the fcntl64 calls. So yes, although I couldn't locate where in the
source, it seems to be hal problem.

Now something equally interesting - hald does execve *10* times with a wrong
path for hald-runner before succeeding!! Shouldn't it do something like try the
most likely path first and failing that should use something like access() to
loate hald-runner. Admittedly a distro shouldn't need to change hald-runner path
and that way it can just be one execve.
 
[pid  4733] execve("/usr/lib/qt-3.3/bin/hald-runner", ["hald-runner"], [/* 2
vars */]) = -1 ENOENT (No such file or directory)
[pid  4733] execve("/usr/kerberos/sbin/hald-runner", ["hald-runner"], [/* 2 vars
*/]) = -1 ENOENT (No such file or directory)
[pid  4733] execve("/usr/kerberos/bin/hald-runner", ["hald-runner"], [/* 2 vars
*/]) = -1 ENOENT (No such file or directory)
[pid  4733] execve("/usr/local/sbin/hald-runner", ["hald-runner"], [/* 2 vars
*/]) = -1 ENOENT (No such file or directory)
[pid  4733] execve("/usr/local/bin/hald-runner", ["hald-runner"], [/* 2 vars
*/]) = -1 ENOENT (No such file or directory)
[pid  4733] execve("/sbin/hald-runner", ["hald-runner"], [/* 2 vars */]) = -1
ENOENT (No such file or directory)
[pid  4733] execve("/bin/hald-runner", ["hald-runner"], [/* 2 vars */]) = -1
ENOENT (No such file or directory)
[pid  4733] execve("/usr/sbin/hald-runner", ["hald-runner"], [/* 2 vars */]) =
-1 ENOENT (No such file or directory)
[pid  4733] execve("/usr/bin/hald-runner", ["hald-runner"], [/* 2 vars */]) = -1
ENOENT (No such file or directory)
Comment 3 Parag Warudkar 2007-03-19 16:21:44 UTC 
Are at least the 1024 fcntl64s on EBADF going to be fixed? I am sure that is bad
enough to need a fix?
Comment 4 Matthias Clasen 2007-10-02 04:21:22 UTC 
Given that hald-runner is installed in /usr/libexec, the following patch should
get rid of the path searching; it also gets rid of the nonworking attempt to set
the PATH for g_spawn_async
Comment 5 Matthias Clasen 2007-10-02 04:22:17 UTC 
Created attachment 213141 [details]
path.patch
Comment 6 Matthias Clasen 2007-10-02 04:33:01 UTC 
The fcntl64 issue is acutally a glib bug and is tracked here:
http://bugzilla.gnome.org/show_bug.cgi?id=469231
Comment 7 Parag Warudkar 2008-03-26 22:49:30 UTC 
Closing - since the main glib bug was fixed in upstream.