Server crash, danach kein Apache start

[Deleted member 4401]

Hallo zusammen...

(Debian Etch)

Meine Frage hat zwar in erster Linie mit dem Apachen zu tun, jedoch denke ich dass es etwas mit dem vServer an sich zu tun hat, deswegen poste ich in diesem Forum (und nicht im Apache Forum).

Zur Sache:
Vor ein paar Tagen crashte der Server, nach einem Reboot verweigert nun der Apache den Start, die Fehlermeldungen sind reichlich seltsam:

/etc/snmp/snmp.conf: Too many open files in system
/etc/snmp/snmp.local.conf: Too many open files in system
/usr/share/snmp/snmp.conf: Too many open files in system
/usr/share/snmp/snmp.local.conf: Too many open files in system
/usr/lib/snmp/snmp.conf: Too many open files in system
/usr/lib/snmp/snmp.local.conf: Too many open files in system
/var/lib/snmp/snmp.conf: Too many open files in system
/var/lib/snmp/snmp.local.conf: Too many open files in system
/etc/snmp/snmpapp.conf: Too many open files in system
/etc/snmp/snmpapp.local.conf: Too many open files in system
/usr/share/snmp/snmpapp.conf: Too many open files in system
/usr/share/snmp/snmpapp.local.conf: Too many open files in system
/usr/lib/snmp/snmpapp.conf: Too many open files in system
/usr/lib/snmp/snmpapp.local.conf: Too many open files in system
/var/lib/snmp/snmpapp.conf: Too many open files in system
/var/lib/snmp/snmpapp.local.conf: Too many open files in system
Cannot find module (IP-MIB): At line 0 in (none)
Cannot find module (IF-MIB): At line 0 in (none)
Cannot find module (TCP-MIB): At line 0 in (none)
Cannot find module (UDP-MIB): At line 0 in (none)
Cannot find module (HOST-RESOURCES-MIB): At line 0 in (none)
Cannot find module (SNMPv2-MIB): At line 0 in (none)
Cannot find module (SNMPv2-SMI): At line 0 in (none)
Cannot find module (NOTIFICATION-LOG-MIB): At line 0 in (none)
Cannot find module (UCD-SNMP-MIB): At line 0 in (none)
Cannot find module (UCD-DEMO-MIB): At line 0 in (none)
Cannot find module (SNMP-TARGET-MIB): At line 0 in (none)
Cannot find module (NET-SNMP-AGENT-MIB): At line 0 in (none)
Cannot find module (HOST-RESOURCES-TYPES): At line 0 in (none)
Cannot find module (UCD-DLMOD-MIB): At line 0 in (none)
Cannot find module (DISMAN-EVENT-MIB): At line 0 in (none)
Cannot find module (UCD-DISKIO-MIB): At line 0 in (none)
Cannot find module (LM-SENSORS-MIB): At line 0 in (none)
Cannot find module (IPV6-ICMP-MIB): At line 0 in (none)
Cannot find module (IPV6-MIB): At line 0 in (none)

usw.

Eine Fehlermeldung gibt mir jedoch besonders zu denken:

[error] Cannot allocate shared memory: (12)Cannot allocate memory

Dies wird wohl von eaccelerator verursacht, dieser lief jedoch mit einem Wert von 64MB seit Jahren einwandfrei.

Am System wurde seit geraumer Zeit nichts geändert (wozu auch, lief ja tadellos), Updates können auch nicht Schuld sein da es für Etch ja nunmal keine mehr gibt, Hinweise auf eine Kompromittierung finden sich auch keine.
Nun glaube ich so langsam dass es etwas mit dem Hostsystem bzw. der Virtualisierung zu tun hat, also dass dort etwas geändert wurde.
Eure Meinung dazu?

Auf dem Server waren zum Glück nur 3 Sites gehostet die ich auf die schnelle auf einen meiner Dedicated verschieben konnte (was sowieso geplant war), das Problem ist also nicht akut aber es würde mich natürlich schon interessieren was die Ursache ist.

 

[wstuermer]

grep -v " 0$" /proc/user_beancounters

 

[Deleted member 4401]

Massig failcounts, zumindest der grösste Teil stammt jedoch von DDoS Angriffen die Monate zurückliegen:

    148170: kmemsize                  4663553             17801065             17777274             19555001           1064315163
            tcpsndbuf                  225592              4154136              4148094              5925758               141143
            tcprcvbuf                  229376              4156336              4148094              5925758                  543

Zum Zeitpunkt des Crashs waren jedoch keine aussergewöhnlichen Zugriffszahlen zu verzeichnen. Und wie gesagt, der Server lief mit der selben Config schon seit Jahren.

 

[Cenic]

Massig failcounts, zumindest der grösste Teil stammt jedoch von DDoS Angriffen die Monate zurückliegen

Nein, die Zähler werden bei einem Reboot, den du ja offenbar gemacht hast, zurückgesetzt: http://wiki.openvz.org/UBC_failcnt_reset:

UBC failcnts are stored for the duration of the uptime of your container. Thus, restarting the container resets the counts.

Edit: Oder nutz du/dein Provider CONFIG_UBC_KEEP_UNUSED?

 

[Deleted member 4401]

Failcounts werden definitiv nicht zurückgesetzt, natürlich kann ich nicht ausschliessen dass nun neue hinzugekommen sind...

Also ich bin überzeugt davon dass Resourcen über die Virtualisierung neu zugeteilt bzw. beschnitten wurden. Es kann ja nicht sein dass eine Konfiguration die seit langer Zeit absolut problemlos lief nun selbst im Idle-Zustand "aus Resourcenmangel" nicht einmal erlaubt den Apache zu starten.

Naja, Kündigung war eh geplant.