Apache en linux-vserver no se iniciará, no se puede crear socket

Durante extensas investigaciones y pruebas para escribir una pregunta adecuada digna de stackexchange he encontrado una solución: reconstruir el paquete libapr1 dentro del invitado.
Pensé que, sin embargo, publicar esta información, ya que podría ser útil a los demás.

Problema

Cuando instalo libapache2-mod-php5 dentro del invitado de Wheezy y trata de iniciar, obtengo lo siguiente:

 root@test01:~# /usr/sbin/apache2ctl start [crit] (22)Invalid argument: alloc_listener: failed to get a socket for (null) Syntax error on line 9 of /etc/apache2/ports.conf: Listen setup failed Action 'start' failed. The Apache error log may have more information. root@test01:~# tail /var/log/apache2/error.log root@test01:~# root@test01:~# head -n 9 /etc/apache2/ports.conf|tail -n 1 Listen 80 

Esta es la instalación de paquete prístina sin cambios que por defecto no logra iniciar.

Mis pruebas

Según la documentación oficial, escuchar 80 es realmente bien . Convertirlo en Listen 127.0.0.1:80 me da:

 [crit] (22)Invalid argument: alloc_listener: failed to get a socket for 127.0.0.1 Syntax error on line 9 of /etc/apache2/ports.conf: Listen setup failed Action 'start' failed. 

¿Por qué Apache fallaría en obtener un socket? Tengo otros deamons funcionando (es decir nginx en la otra instalación de Wheezy; exim4 que escucha en el puerto 25 en la misma instalación) sin problemas.

Ambiente

Anfitrión

Debian Lenny en 2.6.26-2-vserver-amd64

 # vserver-info Versions: Kernel: 2.6.26-2-vserver-amd64 VS-API: 0x00020303 util-vserver: 0.30.216-pre2772; Dec 13 2008, 04:56:19 Features: CC: gcc, gcc (Debian 4.3.2-1) 4.3.2 CXX: g++, g++ (Debian 4.3.2-1) 4.3.2 CPPFLAGS: '' CFLAGS: '-Wall -g -O2 -std=c99 -Wall -pedantic -W -funit-at-a-time' CXXFLAGS: '-g -O2 -ansi -Wall -pedantic -W -fmessage-length=0 -funit-at-a-time' build/host: x86_64-pc-linux-gnu/x86_64-pc-linux-gnu Use dietlibc: yes Build C++ programs: yes Build C99 programs: yes Available APIs: v13,net,v21,v22,v23,netv2 ext2fs Source: e2fsprogs syscall(2) invocation: alternative vserver(2) syscall#: 236/glibc crypto api: beecrypt use library versioning: yes Paths: prefix: /usr sysconf-Directory: /etc cfg-Directory: /etc/vservers initrd-Directory: $(sysconfdir)/init.d pkgstate-Directory: /var/run/vservers vserver-Rootdir: /var/lib/vservers Assumed 'SYSINFO' as no other option given; try '--help' for more information. 

Huésped

Debian Wheezy, construido con vserver $VSERVER build -m debootstrap --hostname $VSERVER --netdev eth0 --context $CONTEXT --interface v$CONTEXT=xyz$CONTEXT/zz -- -d wheezy -m http://apt-proxy:9999/debian/

Investigación hasta el momento

Los internets me proporcionaron las siguientes cosas hasta ahora:

  • Problema en el fedorra fijado por actualización APR
  • Problema resuelto al actualizar el paquete
  • Incompatibilidad del kernel
  • Otra solución requería una actualización del kernel

Mi mayor temor, y esta es mi conclusión actual, es que apache dentro del servidor virtual depende de alguna nueva característica del kernel que mi anfitrión no proporciona. Después de todo, el núcleo predeterminado de Wheezy ciertamente no es tan viejo como mi 2.6.26.

Quiero evitar la actualización del núcleo del host a toda costa.

¿Por qué?

  • Falta de tiempo y conocimientos (el hardware es el servidor HP, no hay idea de lo que hay que tener en cuenta)
  • Wheezy no soporta más vserver (fuera de la caja, para la auto-instalación ver 1) …)
  • Ya se están ejecutando vservers que se requieren para estar disponibles 24/7 (todo el sistema es la empresa interna y no expuestos a Internet)
  • Ningún segundo mismo hardware para realizar pruebas

Estoy dispuesto a parchear Apache

Si es posible averiguar cuál es el problema, estoy dispuesto a construir un paquete deb personalizado para mis misiones Wheezy.

Solución

Como dije en la primera frase, ya encontré la solución: reconstruí el paquete libapr1 dentro del invitado .

Encontré la solución googling para "Invalid argumento: alloc_listener: no pudo obtener un socket para (null)" , el quinto golpe fue Invalid argumento crap que menciona la actualización del núcleo y se refiere a otro blogger hablando de Fedora 11 httpd problemas:

El problema está relacionado con tres llamadas de kernel que se utilizan en apr-1.3.8-1: accept4 (), dup3 () y epoll_create1 (). Sin estas llamadas, apache no puede iniciar.

Él menciona el equipo de Fedora fijo por lo que he comprobado el informe de error: https://bugzilla.redhat.com/show_bug.cgi?id=516331 , específicamente el segundo comentario :

.. si usted construye su propio APR en esa instancia de Xen, recogerá correctamente las funciones más antiguas y funcionará.

Eso sonó una campana. Todo lo que tenía que hacer era reconstruir el paquete libapr1 porque el script configure automáticamente averiguaría que accept4 no está disponible y volverá a accept . Así es como lo hice:

  • apt-get source libapr1
  • tar -xf apr_1.4.6.orig.tar.gz
  • cd apr-1.4.6
  • tar -xf ../apr_1.4.6-3.debian.tar.gz
  • dpkg-buildpackage
    Esto falló en primer lugar debido a las dependencias que faltan: apt-get install debhelper autoconf autotools-dev uuid-dev doxygen libtool
  • Después de algún tiempo esto produjo un paquete debian fuera del directorio que instalé:
    dpkg -i libapr1_1.4.6-3_amd64.deb
  • ¡Entonces apenas comencé apache y trabajó!
    /etc/init.d/apache2 start

En sistemas que carecen de disco, es posible que desee eliminar doxygen después de la compilación: en mi sistema necesitaba más de 600MB junto con sus dependencias.