We've uncovered what appears to be a interesting bug in linux-2.4.32-uc0 from the 20060803 drop.
When syslogd is *not* configured into the kernel, but applications attempt syslog calls, the kernel opens a new file descriptor for each call, but does not close it. Eventually, after enough syslog calls, the kernel runs out of file descriptors. The bug is moot when syslogd *is* configured into the kernel, as syslog then uses the well-known socket and is well behaved. But I thought the uClinux kernel developer's list would be interested in the behavior in any case. Here's the full text from our in-house developer who first discovered the problem: --------%<----------------%<----------------%<----------------%<-------- David's new kernel with syslog enabled fixes a problem I was chasing today. It appears that when syslogd is not running on the [xyz] and the messages are going to console, every single call to syslog() opens a new file descriptor and fails to close it. If you call it 1024 times, the process is out of fds and it can't do much else. But with David's change, the process opens just one socket to syslog and sends every message through that socket as it should. Maybe it's moot now that we have syslog running, but this seems like a pretty serious leak in uClinux to me. Should I file it somewhere? --------%<----------------%<----------------%<----------------%<-------- This developer has also written a uClinux application in C that demonstrates the problem. I can provide it upon request. -- David Spain SiCortex, Inc. Three Clock Tower Place, Suite 210 Maynard, MA USA 01754 _______________________________________________ uClinux-dev mailing list [email protected] http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by [email protected] To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
