Apache dans linux-vserver ne démarre pas, ne peut pas créer de socket


8

Au cours de recherches et de tests approfondis pour écrire une bonne question digne de stackexchange, j'ai trouvé une solution: reconstruire le libapr1package à l'intérieur de l'invité.
J'ai pensé que je publierais néanmoins ces informations car elles pourraient être utiles à d'autres.

Problème

Lorsque j'installe libapache2-mod-php5à l'intérieur de l'invité Wheezy et qu'il essaie de démarrer, j'obtiens ce qui suit:

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

Il s'agit de l'installation du package vierge inchangé qui, par défaut, ne parvient pas à démarrer.

Mes tests

Selon la documentation officielle, Listen 80 est très bien . Le transformer en Listen 127.0.0.1:80me donne:

[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.

Alors pourquoi Apache ne parviendrait-il pas à obtenir un socket? J'ai d'autres démons en cours d'exécution (ie nginx sur une autre installation Wheezy; exim4 écoute sur le port 25 sur la même installation) sans problèmes.

Environnement

Hôte

Debian Lenny sur 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.

Client

Debian Wheezy, construit avec vserver $VSERVER build -m debootstrap --hostname $VSERVER --netdev eth0 --context $CONTEXT --interface v$CONTEXT=x.y.z.$CONTEXT/zz -- -d wheezy -m http://apt-proxy:9999/debian/

Recherches à ce jour

Jusqu'à présent, les internets m'ont fourni les choses suivantes:

Ma plus grande crainte, et c'est ma conclusion actuelle, est qu'apache à l'intérieur du serveur virtuel dépend d'une fonctionnalité de noyau plus récente que mon hôte ne fournit pas. Après tout, le noyau par défaut de Wheezy n'est certainement pas aussi ancien que mon 2.6.26.

Je veux éviter à tout prix de mettre à niveau le noyau hôte.

Pourquoi?

  • Manque de temps et de connaissances (le matériel est un serveur HP, aucune idée de quoi faire attention)
  • Wheezy ne prend plus en charge vserver (prêt à l'emploi; pour l'auto-installation, voir 1) ...)
  • Vous utilisez déjà des vservers qui doivent être disponibles 24h / 24 et 7j / 7 (l'ensemble du système est interne à l'entreprise et n'est pas exposé à Internet)
  • Pas de deuxième matériel identique pour effectuer les tests

Je suis prêt à patcher Apache

S'il est possible de comprendre quel est le problème, je suis prêt à créer un package deb personnalisé pour mes quêtes Wheezy.

Réponses:


16

Solution

Comme je l'ai dit dans la première phrase, j'ai déjà trouvé la solution: j'ai reconstruit le libapr1package à l'intérieur de l'invité .

J'ai trouvé la solution en recherchant "Argument invalide: alloc_listener: échec d'obtention d'un socket pour (null)" , le 5ème coup était une merde d'argument invalide qui mentionne la mise à niveau du noyau et fait référence à un autre blogueur parlant des problèmes httpd de Fedora 11 :

Le problème est lié à trois appels de noyau utilisés dans apr-1.3.8-1: accept4 (), dup3 () et epoll_create1 (). Sans ces appels, apache ne peut pas démarrer.

Il mentionne que l'équipe Fedora a été corrigée, j'ai donc vérifié le rapport de bogue: https://bugzilla.redhat.com/show_bug.cgi?id=516331 , en particulier le deuxième commentaire :

.. si vous construisez votre propre APR sur cette instance Xen, il reprendra correctement les anciennes fonctions et fonctionnera ..

Cela a sonné une cloche. Tout ce que j'avais à faire était de reconstruire le libapr1paquet car le script de configuration découvrira automatiquement qu'il accept4n'est pas disponible et reviendra à accept. Voilà comment je l'ai fait:

  • 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
    Cela a échoué au début en raison de dépendances manquantes: apt-get install debhelper autoconf autotools-dev uuid-dev doxygen libtool
  • Après un certain temps, cela a produit un paquet Debian en dehors du répertoire que j'ai installé:
    dpkg -i libapr1_1.4.6-3_amd64.deb
  • Ensuite, je viens de commencer Apache et cela a fonctionné!
    /etc/init.d/apache2 start

Sur un système privé de disque, vous souhaiterez peut-être supprimer doxygen après la compilation: sur mon système, il avait besoin de plus de 600 Mo avec ses dépendances.


+1 Merci, très utile et cela a aussi résolu mon problème dans serverfault.com/questions/506238/… Vous devez marquer votre propre réponse comme étant acceptée.
aseq

pas un tel paquet
Flash Thunder
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.