Am 04.05.2017 um 12:11 schrieb Denny Jahnke:
Hallo zusammen,
ich habe ein größeres Problem, welches auch nicht wirklich beständig ist, ich
hoffe es kann mir jemand einen Tipp geben.
Folgende Konstellation:
Server-OS: Debian 8.7
HTTPD: Apache/2.4.10 (Debian) - über APT installiert
RAM: 32GB
CPU: 24 vCores
Nutzung: als Reverse Proxy (kein Forward Proxy von innen ins Internet!) für
verschiedene Backend Applikationen, hinzu kommen diverse unterschiedliche
Balancer-Konfigurationen über mod_proxy_balancer. Kein PHP/FPM/PERL oder so,
nur zum Teil static content.
Wir haben 2 Systeme die HA über eine vorgeschaltete F5 LB redundant ausgelegt
sind.
Das Verhalten:
Ich habe kleinere Rewrite Änderungen in 2-3 Vhosts durchgeführt (hauptsächlich Rewrites)
und diese auf die Server übertragen, als ich "service apache2 reload"
(configtest war zuvor erfolgreich!) auf dem 1. System durchgeführt habe ist dieser mir
unter den Händen weggestorben, Ports waren auch weg. Fork-Prozesse aber teils noch
vorhanden.
Folgende Fehlermeldung kam zum Vorschein in der error.log:
[Thu May 04 06:25:07.104831 2017] [mpm_worker:notice] [pid 17256:tid
140267085170560] AH00292: Apache/2.4.10 (Debian) OpenSSL/1.0.1t configured --
resuming normal operations
[Thu May 04 06:25:07.104876 2017] [core:notice] [pid 17256:tid 140267085170560]
AH00094: Command line: '/usr/sbin/apache2'
[Thu May 04 06:25:12.284974 2017] [mpm_worker:notice] [pid 17256:tid
140267085170560] AH00297: SIGUSR1 received. Doing graceful restart
[Thu May 04 06:25:13.181387 2017] [slotmem_shm:error] [pid 17256:tid
140267085170560] (28)No space left on device: AH02611: create:
apr_shm_create(/var/run/apache2/slotmem-shm-p9e1d2282_internet_cluster.shm)
failed
[Thu May 04 06:25:13.181438 2017] [:emerg] [pid 17256:tid 140267085170560]
AH00020: Configuration Failed, exiting
Allerdings ist mehr als genug Platz auf /var:
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/swrvp1-var_vol 485G 9.5G 451G 3% /var
Ich habe die Konfigurationen aus dem Backup wieder hergestellt, ein "service apache2
restart" hat die gleiche Fehlermeldung produziert. Erst als ich ein killall auf die
verbliebenen Prozesse gemacht habe konnte ich mit einem sauberen Start den Apache wieder
hoch bringen.
Zur Sicherheit habe ich die Konfigurationen auf dem zweiten Apache (der keinen
reload gemacht hat) wieder zurück geändert. Da allerdings die Apaches
regelmäßig neu gestartet werden, kam es hier (obwohl alte Konfiguration!) zu
dem gleichen Fehlerbild und -meldung im error.log innerhalb von ca. 12 Stunden.
Jetzt laufen beide Systeme wieder augenscheinlich stabil und machen den reload
ohne Probleme aber den Fehler hatte ich vor 1 Monat schon mal aber nur auf
einem der beiden Systeme.
Hat jemand eine Idee oder stand schon mal vor dem selben Problem?
Sehr wahrscheinlich sind IPC-Ressourcen erschöpft. In dem Fall hier wohl
Shared Memory (siehe ipcs -m zum Anzeigen, bzw. ipcs -lm zur Anzeige der
konfigurierten Limits, ipcrm zum Löschen), es können aber auch mal
Semaphoren sein (bei ipcs immer statt "-m" ein "-s").
IPC-Ressourcen können leaken, zum Beispiel wenn Prozesse crashen. D.h.
schauen, dass alle Apaches unten sind, dann mit ipcs nachsehen, welche
shared Memory-Segmente und Semaphoren noch belegt sind und ob der User
passt, dann ggf. mit ipcrm löschen und die Apaches wieder starten.
Bei vielen Workern und Load Balancern in mod_proxy kann es auch sein,
dass die eingestellten System-Limits für Shared Memory oder Semaphoren
zu klein sind.
Den Fehler sollte man auch ganz gut mit
strace -v -f -o /var/tmp/strace.out service apache2 start
sehen können (in der großen Datei /var/tmp/strace.out), weil dort jeder
system call mit Ergebniscode drin steht und an der entscheidenden Stelle
dann ein "ENOSPC" auftauchen wird (der Fehlerwert für "No space left on
device").
Mit "restart" wird strace nicht gehen, weil da ja nur ein Signal an den
Apache Vater-Prozess gesendet wird und das Signal-Senden ja klappt. Da
müsste man den laufenden Vater-Prozess vorher in das strace rein nehmen.
Ist aber einfacher mit frischem Apache-Start.
Grüße sendet
Rainer Jung
--
kippdata
informationstechnologie GmbH Tel: 0228 98549 -0
Bornheimer Str. 33a Fax: 0228 98549 -50
53111 Bonn www.kippdata.de
HRB 8018 Amtsgericht Bonn / USt.-IdNr. DE 196 457 417
Geschäftsführer: Dr. Thomas Höfer, Rainer Jung, Sven Maurmann
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]