Can anyone help with this?
We have an application that runs fine on our linux workstations, but
will not compile to run on a new target. This application is using
the WNOWAIT option for the waitid() function. When the source file is
compiled for the target using powerpc-uclibc-gcc, it fails because
WNOWAIT is not defined. The best that I can tell, waitid() doesn't
appear to be supported in uClibc (version 0.9.27). I checked the
latest version on the uClibc site, but it doesn't appear to have been
considered for inclusion. I looked in glibc (versions 2.4, 2.3.5, and
2.0.6), but could only find emulated/stub/pseudo implementations for
waitid(). The Linux man page for waitid() states that it's supported
since the 2.6.9 kernel release. At this point I'm not sure where the
waitid() source code and WNOWAIT definition is suppose to be (kernel,
uClibc, glibc, gcc) or what version of wait.h is actually being used
(there appears to be many versions floating around on the machine).
Since I'm way off in the weeds on this I was hoping somebody with more
Linux experience than me (that would be just about anyone) might be
able to shed some light on this problem or point me in a more
constructive direction.
Do you have any information as to the status of the waitid() support?
It must have been available at one time since it's running on my linux
workstation (Linux version 2.6.15-1.2054_FC5smp
([email protected]) (gcc version 4.1.0 20060304
(Red Hat 4.1.0-3)) #1 SMP Tue Mar 14 16:05:46 EST2006).
Was there a reason why it wasn't added to uClibc (other than the size issue)?
Is there a recommended way to deal with applications that are using
waitid() with the WNOWAIT option?
Thanks for any assistance,
Sue
You're asking the wrong list. Try the uClibc list at uclibc.org.
glibc and uClibc provide C APIs to kernel system calls. uClibc doesn't
implement all features that glibc supports - there are several kernel
APIs that uClibc doesn't expose. Ask the uClibc folk for advice.
--
James Chapman
Katalix Systems Ltd
http://www.katalix.com
Catalysts for your Embedded Linux software development
Sue Alfano wrote:
> Can anyone help with this?
>
> We have an application that runs fine on our linux workstations, but
> will not compile to run on a new target. This application is using
> the WNOWAIT option for the waitid() function. When the source file is
> compiled for the target using powerpc-uclibc-gcc, it fails because
> WNOWAIT is not defined. The best that I can tell, waitid() doesn't
> appear to be supported in uClibc (version 0.9.27). I checked the
> latest version on the uClibc site, but it doesn't appear to have been
> considered for inclusion. I looked in glibc (versions 2.4, 2.3.5, and
> 2.0.6), but could only find emulated/stub/pseudo implementations for
> waitid(). The Linux man page for waitid() states that it's supported
> since the 2.6.9 kernel release. At this point I'm not sure where the
> waitid() source code and WNOWAIT definition is suppose to be (kernel,
> uClibc, glibc, gcc) or what version of wait.h is actually being used
> (there appears to be many versions floating around on the machine).
> Since I'm way off in the weeds on this I was hoping somebody with more
> Linux experience than me (that would be just about anyone) might be
> able to shed some light on this problem or point me in a more
> constructive direction.
>
> Do you have any information as to the status of the waitid() support?
> It must have been available at one time since it's running on my linux
> workstation (Linux version 2.6.15-1.2054_FC5smp
> ([email protected]) (gcc version 4.1.0 20060304
> (Red Hat 4.1.0-3)) #1 SMP Tue Mar 14 16:05:46 EST2006).
>
> Was there a reason why it wasn't added to uClibc (other than the size
> issue)?
>
> Is there a recommended way to deal with applications that are using
> waitid() with the WNOWAIT option?
>
> Thanks for any assistance,
> Sue
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Well, I'm back. I didn't get any help from the uClibc folks, but I eventually
figured out how to get to the waitid function in the kernel using the _syscall4
macro and the right header file. waitid worked great, but then I started
having problems when more than one child needed to be reaped.
Basically, the parent process registers a SIGCHLD signal handler via sigaction()
with the SA_RESTART option and then sits on a timed select(). All the signal
handler does is set a flag - the waitid processing takes place when the parent
drops out of the select because of the signal or a timeout. When the waitid
succeeds, the pid is used to do some processing and then is used to call
waitpid to clean up the mess. This is all in a while loop, so when the waitid
is called again, 0 is returned with si_pid = 0 indicating that there are no
more children to reap. That's all great. The problem occurs when there's 2
or more children to reap. When this occurs, the 2nd waitid call returns -1
and si_pid = 0. The waitid continues to fail in this manner until the parent
receives another SIGCHLD signal, then it works for the next zombie child in
the waiting line, but only one. I can send SIGCHLD kills to the parent from
the console and eventually get everything cleaned up. Sending the kill from
the parent isn't enough - I suppose it wants to be blocking on the select.
I tried registering the signal handler without SA_RESRART and also via signal(),
since there was a posting about SA_RESTART, but that made no difference. I
also tried not having a signal handler at all, but then I couldn't reap any
children on the timeout.
So, are there known issues with waitid when there are multiple children piled
up waiting to be reaped? If so, is there a patch or a workaround?
The product that I'm working on is using Linux version 2.6.12-2.0.0-258
Thanks for any help,
Sue
On 1/18/07, James Chapman <[email protected]> wrote:
> You're asking the wrong list. Try the uClibc list at uclibc.org.
>
> glibc and uClibc provide C APIs to kernel system calls. uClibc doesn't
> implement all features that glibc supports - there are several kernel
> APIs that uClibc doesn't expose. Ask the uClibc folk for advice.
>
> --
> James Chapman
> Katalix Systems Ltd
> http://www.katalix.com
> Catalysts for your Embedded Linux software development
>