Feature #2883

fdevent_init should check if SOCK_NONBLOCK works

Added by staples1347 11 months ago. Updated 6 months ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
Missing in 1.5.x:


In src/fdevent.c, fdevent_init only checks if SOCK_CLOEXEC works, but doesn't check if SOCK_NONBLOCK works as well. It also doesn't use fcntl to double-check that the SOCK_CLOEXEC flag has been applied.

I have an Android Acer Iconia A500 running a custom rom with kernel: and for some reason SOCK_NONBLOCK is ignored when passed to socket but an error isn't returned. This occurs even when I compile with NDK API: 21 where SOCK_NONBLOCK is supported instead of NDK API: 14. The attached test program: testsocketnonblock.c displays 1 for Cloexec but 2 for Nonblock (2 means an error wasn't returned from the call to socket, but the fcntl test returned that the flag wasn't set). On my laptop with Linux Gentoo kernel: 4.14.32-gentoo, both tests return 1. Without a workaround, this causes lighttpd to freeze when running on my tablet when multiple html files are requested by a client browser.

testsocketnonblock.c (787 Bytes) testsocketnonblock.c staples1347, 2018-04-10 07:40

Associated revisions

Revision 78024584 (diff)
Added by gstrauss 7 months ago

[core] check if SOCK_NONBLOCK is ignored (fixes #2883)

"fdevent_init should check if SOCK_NONBLOCK works"



Updated by gstrauss 11 months ago

  • Tracker changed from Bug to Feature
  • Target version changed from 1.4.50 to 1.4.x

for some reason SOCK_NONBLOCK is ignored when passed to socket but an error isn't returned.

That's pretty ridiculous and arguably a bug in that version of Android or the custom ROM

SOCK_CLOEXEC and SOCK_NONBLOCK were added in the later part of the 2.6 kernel series. There are comments in fdevent.c which refer to and note that SOCK_CLOEXEC might not work in kernels prior to 2.6.27.

I'll look into adding some checks in lighttpd, but don't like the idea of lighttpd having to validate many different types of operating system behavior at startup. Have you filed a bug for that version of Android? lighttpd is probably not the only application affected by this.


Updated by staples1347 11 months ago

Yes it is ridiculous and I already figured it is a bug on the tablet as the kernel version is high enough to support SOCK_NONBLOCK, but this tablet and others like it might not be getting any more system updates (I mainly use it to make sure our project still works with old Android devices). I haven't yet posted a bug report to Android I am going to check if Google's Android Emulators also have the bug first, the reason why I only just noticed this issue is I've been updating the build system that we use for the project that the company I work for is working on and the previous Android NDK we were using didn't define SOCK_CLOEXEC or SOCK_NONBLOCK when targeting older Android versions.

My main reason for filing the bug in lighttpd though was that other Android or even non-Android or non-Linux systems may be affected where a user compiles the latest lighttpd on a dev system that defines SOCK_NONBLOCK, but the system they deploy to has this issue but for whatever reason they are unable to update their operating system/libraries, and since lighttpd already had some checks for SOCK_CLOEXEC it seemed like adding additonal checks as per the test program would be fairly straight forward.


Updated by gstrauss 11 months ago

where a user compiles the latest lighttpd on a dev system that defines SOCK_NONBLOCK, but the system they deploy to has this issue

It is often unwise to compile and build on a system with libraries newer than the target systems to which it will be deployed. If your cross-compilation environment provides the definitions for SOCK_NONBLOCK, then it is reasonable to assume that the target system will be running kernels that support SOCK_NONBLOCK or that the system libraries will properly return an error, e.g EINVAL for the unsupported flag.


I have posted a preliminary patch to my personal/gstrauss/master branch. See DevelGit


Updated by staples1347 10 months ago

It looks like that patch has fixed the problem on my tablet. Thanks. I have also tested various Android versions with Android Emulator and they don't appear to have the problem.


Updated by gstrauss 10 months ago

  • Status changed from New to Patch Pending
  • Target version changed from 1.4.x to 1.4.50

Updated by gstrauss 6 months ago

  • Status changed from Patch Pending to Fixed
  • % Done changed from 0 to 100

Also available in: Atom