Feature #2998

accept4 returns EPERM instead of ENOSYS on some platforms

Added by alex-che 7 months ago. Updated 6 months ago.

Target version:


I'm working on embedded Freescale ARM Linux, kernel 2.6.35, glibc 2.21. On this platform:
1) accept4() system call is not supported,
2) glibc returns EPERM instead of ENOSYS for missing implementations.
For this reason the fdevent_accept_listenfd() wrapper in fdevent.c does not fallback to calling accept() after trying to call accept4(), and just fails.
After I added || errno == EPERM to the else if clause near the line 594, everything works fine.


Updated by gstrauss 7 months ago

linux kernel 2.6.35 was released 1 Aug 2010, about 9 1/2 years ago. ( )
glibc 2.21 was released 6 Feb 2015 ( )

Why such a disparity in release dates?


Updated by gstrauss 7 months ago

Please double-check your versions and the kernel headers against which you cross-compiled glibc and the kernel.

According to the man page for accept4() on a (modern!) Linux system:

The accept4() system call is available starting with Linux 2.6.28; support in glibc is available starting with version 2.10.

The man page also documents:

In addition, Linux accept() may fail if:

EPERM Firewall rules forbid connection.

Your suggested fix is at odds with the documentation in the man page.


Updated by alex-che 7 months ago

The docs was the first thing I checked. I completely agree that EPERM is not the expected error for this case. That's why it took me too much time to find the real reason.

I develop an app which needs to run on an old platform, which I cannot upgrade. A lot of modern libraries won't compile with the original ARM GCC toolchain used for that platform, that's why I use newer toolchain and copy the whole bunch of needed libs, including, to the platform, so that they are used instead of the original libs of the platform. Hence the version disparity.

As to accept4() syscall availability. According to some sources accept4() was not added to all platforms on 2.6.28. E.g., it was added to ARM only on 2.6.36. Please, see or just google 'ARM accept4'. Given that my ARM kernel is 2.6.35, it looks likely.

I also found several mentions that on some systems EPERM is incorrectly returned in case of missing syscall table implementation. E.g., see or or

Actually, I understand that this case is pretty exotic. And I can understand if you're not willing to change lighttpd code to support undocumented and highly unprobable cases. On the other hand, adding one more error code to the if clause seems to be a tiny code change, which won't break anything, since if EPERM in accept4() is really caused by the firewall (as per documentation), then the accept() should fail with the same error code as well.


Updated by gstrauss 6 months ago

  • Tracker changed from Bug to Feature
  • Status changed from New to Patch Pending
  • Target version changed from 1.4.x to 1.4.55
--- a/src/fdevent.c
+++ b/src/fdevent.c
@@ -629,9 +629,18 @@ int fdevent_accept_listenfd(int listenfd, struct sockaddr *addr, size_t *addrlen
                                        fd = -1;
-               } else if (errno == ENOSYS || errno == ENOTSUP) {
-                       fd = accept(listenfd, addr, &len);
-                       sock_cloexec = 0;
+               }
+               else {
+                       switch (errno) {
+                       case ENOSYS:
+                       case ENOTSUP:
+                       case EPERM:
+                               fd = accept(listenfd, addr, &len);
+                               sock_cloexec = 0;
+                               break;
+                       default:
+                               break;
+                       }
        else {

Updated by gstrauss 6 months ago

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

Also available in: Atom