I have compiled httpd 2.0.45 on NetBSD/sparc with option --enable-mods-shared=all and the error [error] (35)Resource temporarily unavailable: apr_accept: (client socket) appears continuosly on the log when running. Playing with the prefork configuration I have found that only one subprocess can be waiting on accept, other subprocesses get error 35 from the OS and die (then the master proccess spawns another proccess that tries to accept again and fails, etc., etc.). I have 2.0.44 installed with the same conf and it works fine. Bye, - Salva
This has been reported before (we need to see if it is still open). Can you try adding a second listening socket to see if the symptom goes away? With > 1 listening socket, Apache will need to mutex around a poll+accept call, so you won't have multiple processes in accept at the same time, and perhaps that circumvents whatever is going wrong. Alternatively, find this code in configure.in: *486-*-bsdi* | *-netbsd* | *-freebsd* | *-apple-darwin* | *-dec-osf* | *-qnx) APR_SETVAR(SINGLE_LISTEN_UNSERIALIZED_ACCEPT, [1]) ;; delete those three lines, make extraclean && ./buildconf && ./configure --whatever && make && make install and see if the symptom goes away without having to add an additional listening socket as far as real problem resolution, I suspect this needs some dedicated debugging :)
After some debugging I have found what the problem is: NetBSD has IPv6 support but I have dissabled it on my server kernel. apr configure finds the header files and gets erroneously compiled for IPv6. If I add the --disable-ipv6 option everything runs fine again. The question open now is why "resource temporarily unavailable", opening the IPv6 socket should have failed from the first time. Bye, - Salva
good debugging! Also, using IPv4 statement on Listen directive should do it too Listen 0.0.0.0 80 Note that Apache has some logic to try to look for weird IPv6 setups, where we can get an IPv6 socket but it still isn't valid to use an IPv6 socket. That logic is in file server/listen.c in function find_default_family(). It would be nice to modify it to handle a setup like yours, but if your symptom is that one process blocked in accept() is okay but additional sockets in accept() get EAGAIN, I doubt that we can do anything about it. (I'd fear that such a complicated test at startup would create more problems than it is worth.)
Is this still reproducible with 2.0.53?
Closing due to inactivity, length of time and absence of of user information. If more information appears later, please re-open the bug.