Während umfangreicher Recherchen und Tests, um eine richtige Frage zu schreiben, die dem Stapelaustausch würdig ist, habe ich eine Lösung gefunden: Erstellen Sie das libapr1Paket im Gast neu.
Ich dachte, ich würde diese Informationen trotzdem veröffentlichen, da sie für andere nützlich sein könnten.
Problem
Wenn ich libapache2-mod-php5im Wheezy-Gast installiere und dieser versucht zu starten, wird Folgendes angezeigt:
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
Dies ist die unveränderte, makellose Paketinstallation, die standardmäßig nicht gestartet werden kann.
Meine Tests
Laut der offiziellen Dokumentation ist Listen 80 tatsächlich in Ordnung . Das zu verwandeln Listen 127.0.0.1:80gibt mir:
[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.
Warum sollte Apache keinen Socket bekommen? Ich habe andere Deamons ohne Probleme ausgeführt (z. B. Nginx bei einer anderen Wheezy-Installation; exim4 überwacht Port 25 bei derselben Installation).
Umgebung
Wirt
Debian Lenny am 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.
Gast
Debian Wheezy, gebaut mit 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/
Forschung bisher
Das Internet hat mir bisher folgende Dinge bewiesen:
- Problem mit Fedorra durch Upgrade des APR behoben
- Problem durch Upgrade des Pakets behoben
- Kernel-Inkompatibilität
- Eine andere Lösung erforderte ein Kernel-Upgrade
Meine größte Angst, und dies ist meine derzeitige Schlussfolgerung, ist, dass Apache im virtuellen Server von einer neueren Kernelfunktion abhängt, die mein Host nicht bietet. Immerhin ist der Wheezy-Standardkernel sicherlich nicht so alt wie mein 2.6.26.
Ich möchte unbedingt vermeiden, den Host-Kernel zu aktualisieren.
Warum?
- Mangel an Zeit und Wissen (Hardware ist HP Server, keine Ahnung, was zu beachten ist)
- Wheezy unterstützt vserver nicht mehr (sofort einsatzbereit; Selbstinstallation siehe 1) ...)
- Es werden bereits vserver ausgeführt, die rund um die Uhr verfügbar sein müssen (das gesamte System ist unternehmensintern und nicht dem Internet ausgesetzt).
- Keine zweite gleiche Hardware zum Durchführen von Tests
Ich bin bereit, Apache zu patchen
Wenn es möglich ist, das Problem herauszufinden, möchte ich ein benutzerdefiniertes Deb-Paket für meine Wheezy-Quests erstellen.