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:
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.)
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)
Are at least the 1024 fcntl64s on EBADF going to be fixed? I am sure that is bad enough to need a fix?
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
Created attachment 213141 [details] path.patch
The fcntl64 issue is acutally a glib bug and is tracked here: http://bugzilla.gnome.org/show_bug.cgi?id=469231
Closing - since the main glib bug was fixed in upstream.