This Time Self-Hosted
dark mode light mode Search

Beware of the new apr! — Workaround for cross-builds needed

So in the past few days the new apr version marked stable in Gentoo for a series of security problems and all the stable users are suggested to upgrade. Pay attention if you do.

I went updating it today on this server, and found out that Apache failed to start afterward, lamenting inability to open the listening socket; after finding this in the change log for apr itself, I found the problem:

Set CLOEXEC flags where appropriate. Either use new O_CLOEXEC flag and associated functions, such as dup3(), accept4(), epoll_create1() etc., or simply set CLOEXEC flag using fcntl(). PR 46425. [Stefan Fritsch, Arkadiusz Miskiewicz]

Checking the configure.in file, this came out, as well:

AC_CACHE_CHECK([for SOCK_CLOEXEC support], [apr_cv_sock_cloexec],
[AC_TRY_RUN([
#include 
#include 

int main()
{
    return socket(AF_INET, SOCK_STREAM|SOCK_CLOEXEC, 0) == -1;
}], [apr_cv_sock_cloexec=yes], [apr_cv_sock_cloexec=no], [apr_cv_sock_cloexec=no])])

if test "$apr_cv_sock_cloexec" = "yes"; then
   AC_DEFINE([HAVE_SOCK_CLOEXEC], 1, [Define if the SOCK_CLOEXEC flag is supported])
fi

It’s testing if the build system supports CLOEXEC to forcefully enable it on the host system without fallback. This is failing for me because the build system is Yamato and the host sytsem is Vanguard; the former supports CLOEXEC, the latter doesn’t. Just forcing cloexec to be turned off (by setting apr_cv_sock_cloexec=no before merging, fooling the cache system) stops it from requesting CLOEXEC and thus let Apache listen to the socket.

Unfortunately this doesn’t really fix the issue entirely: after that, Apache starts but all its children segfault; since I don’t have enough debug information on Vanguard, I stopped debugging here; I’m not happy about this happening just before my vacation, I guess I’ll have to spend this weekend debugging the issue…

Update!

After thinking about it a bit, I noticed that the code also checks for epoll_create1() even if CLOEXEC is not found (quite foolish); as it turns out, that is what makes Apache children’s crash. So if you are crossbuilding like I am (quite common for servers), you want to set these two variables in your make.conf until apr upstream solves the issue:

apr_cv_sock_cloexec=no
apr_cv_epoll_create1=no

Update #2!

I’ve reported this upstream with a tentative solution proposal, but I probably won’t work on it before my vacation.

Comments 4
  1. I just wanted to say thank you for the such hard core job. It’s mostly invisible all the time but one of most important from my point of view.

  2. A bad example, for sure… yes I will write about this in particular but I’ll have to introduce a few more concepts before that 🙂

  3. I really don’t see the need for much more clarification. the developers upstream shouldn’t be setting host, target, or build is my take. Should be a builders or distributors job. Maybe during testing it never got backed out?

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.