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:
- Problème sur Fedorra résolu par la mise à niveau d'APR
- Problème résolu par la mise à niveau du package
- Incompatibilité du noyau
- Une autre solution a nécessité une mise à niveau du noyau
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.
la source