Durante ricerche e test approfonditi per scrivere una domanda adeguata degna di stackexchange ho trovato una soluzione: ricostruire il libapr1
pacchetto all'interno del guest.
Ho pensato comunque di pubblicare queste informazioni in quanto potrebbero essere utili ad altri.
Problema
Quando installo libapache2-mod-php5
all'interno del guest Wheezy e tenta di avviarsi, ottengo quanto segue:
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
Questa è l'installazione del pacchetto incontaminata invariata che per impostazione predefinita non riesce ad avviarsi.
I miei test
Secondo la documentazione ufficiale, Listen 80 va davvero bene . Trasformandolo in Listen 127.0.0.1:80
mi dà:
[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.
Quindi perché Apache non dovrebbe ottenere un socket? Ho altri deamon in esecuzione (es. Nginx su un'altra installazione di Wheezy; exim4 in ascolto sulla porta 25 della stessa installazione) senza problemi.
Ambiente
Ospite
Debian Lenny su 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.
ospite
Debian Wheezy, costruito con 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/
Ricerca finora
Finora le Internet mi hanno dimostrato con le seguenti cose:
- Problema su fedorra risolto aggiornando APR
- Problema risolto aggiornando il pacchetto
- Incompatibilità del kernel
- Un'altra soluzione ha richiesto un aggiornamento del kernel
La mia più grande paura, e questa è la mia attuale conclusione, è che l'apache all'interno del server virtuale dipende da alcune nuove funzionalità del kernel che il mio host non fornisce. Dopotutto, il kernel predefinito di Wheezy non è certamente vecchio quanto il mio 2.6.26.
Voglio evitare di aggiornare il kernel host a tutti i costi.
Perché?
- Mancanza di tempo e conoscenza (l'hardware è un server HP, non ho idea di cosa fare attenzione)
- Wheezy non supporta più vserver (pronto all'uso; per l'autoinstallazione vedere 1) ...)
- Esegui già server virtuali che devono essere disponibili 24 ore su 24, 7 giorni su 7 (l'intero sistema è interno all'azienda e non esposto a Internet)
- Nessun secondo stesso hardware per eseguire i test
Sono disposto a rattoppare Apache
Se è possibile capire qual è il problema, sono pronto a creare un pacchetto deb personalizzato per le mie ricerche su Wheezy.