[GELÖST] Seltsames Verhalten von "systemctl reload apache2"

[JamesByrnes]

Guten Abend,

ich verstehe die Welt nicht mehr. Ich habe von einem Bullseye-System einen Apache2 umgezogen. Also neu aufgesetzt und die Config-Files und vhosts sowie die Root-Verzeichnisse auf den neuen Server rübersynchronisiert. Einige Domains haben auch Letsencrypt-Zertifikate, auch die habe ich synchronisiert.
Wenn ich zum Beispiel

Code: Alles auswählen

a2ensite 006-headlight.de.conf && systemctl reload apache2

durchführe, dann kommt die Fehlermeldung:

Job for apache2.service failed because a fatal signal was delivered to the control process.
See "systemctl status apache2.service" and "journalctl -xeu apache2.service" for details.

Code: Alles auswählen

░░ The process' exit code is 'killed' and its exit status is 6.
Apr 10 19:00:42 web systemd[1]: apache2.service: Failed with result 'signal'.
░░ Subject: Unit failed
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░ 
░░ The unit apache2.service has entered the 'failed' state with result 'signal'.
Apr 10 19:00:42 web systemd[1]: Reload failed for apache2.service - The Apache HTTP Server.
░░ Subject: A reload job for unit apache2.service has finished
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░ 
░░ A reload job for unit apache2.service has finished.
░░ 
░░ The job identifier is 4688 and the job result is failed.

Wenn ich dann aber wieder

Code: Alles auswählen

systemctl start apache2

durchführe, läuft der Server wieder.
Ich bin jetzt ratlos, denn ich finde den Fehler bei "systemctl reload apache2" nicht. Und ich verstehe es auch nicht, wenn ein Reload nicht funktioniert, ein Restart aber schon.
Habt Ihr Ideen, bzw. welche Debuging-Möglichkeiten bietet Apache dafür an?

Grüße
James

[oln]

Moin,
geht der Reload generell nicht. Also Ohne vorher eine Seite zu enablen?
Edit:
Hiermit überprüfst du die Config:

Code: Alles auswählen

apache2ctl configtest

Du kannst natürlich dem Log folgen.

Code: Alles auswählen

journalctl -u apache2.service -f

Dann mal den Reload ausführen und schauen was das log sagt.

[JamesByrnes]

Hallo und guten Morgen,

geht der Reload generell nicht. Also Ohne vorher eine Seite zu enablen?

Du hast es richtig erfasst! Das Journal liefert bei beliebigen Reload

Code: Alles auswählen

Apr 12 11:17:06 web systemd[1]: Reloading apache2.service - The Apache HTTP Server...
Apr 12 11:17:06 web systemd[1]: apache2.service: Main process exited, code=killed, status=6/ABRT
Apr 12 11:17:06 web systemd[1]: apache2.service: Failed with result 'signal'.
Apr 12 11:17:06 web systemd[1]: Reload failed for apache2.service - The Apache HTTP Server.
Apr 12 11:17:07 web systemd[1]: apache2.service: Scheduled restart job, restart counter is at 2.
Apr 12 11:17:07 web systemd[1]: Stopped apache2.service - The Apache HTTP Server.
Apr 12 11:17:07 web systemd[1]: Starting apache2.service - The Apache HTTP Server...
Apr 12 11:17:07 web systemd[1]: Started apache2.service - The Apache HTTP Server.

Status sagt aber, dass er

Code: Alles auswählen

systemctl status apache2
● apache2.service - The Apache HTTP Server
     Loaded: loaded (/lib/systemd/system/apache2.service; enabled; preset: enabled)
     Active: active (running) since Fri 2024-04-12 11:17:07 CEST; 2min 15s ago

eben doch etwas gemacht hatte - die 2 min 15 sec dürften mein Schreiben hier sein.

Den Configtest hatte ich bereits berücksichtigt. Der ist Ok, ansonsten hätte ich den Fehler sicherlich gefunden.

[JamesByrnes]

Ich weiß nicht, ob das auch wichtig ist. Die /var/log/apache2/error.log füllt sich im Sekundentakt mit Einträgen wie diesem

Code: Alles auswählen

[Fri Apr 12 11:22:40.737843 2024] [core:notice] [pid 106838] AH00052: child pid 106904 exit signal Segmentation fault (11)

Dazu hatte ich im Internet einige Aussagen gefunden. U.A. das hier

Code: Alles auswählen

# apache2 -X
[Fri Apr 12 11:24:22.700789 2024] [core:warn] [pid 106936] AH00111: Config variable ${APACHE_RUN_DIR} is not defined
apache2: Syntax error on line 80 of /etc/apache2/apache2.conf: DefaultRuntimeDir must be a valid directory, absolute or relative to ServerRoot

In /etc/apache2/apache2.conf steht in Zeile 80:

DefaultRuntimeDir ${APACHE_RUN_DIR}

Wobei mein Vim (syntax on) die gesamte Zeile schwarz anzeigt, während ansonsten die Parameter links von den Werten in Türkis angezeigt werden. Und in der /etc/apache2/envvars
steht der Eintrag

Code: Alles auswählen

export APACHE_RUN_DIR=/var/run/apache2$SUFFIX

Vielleicht hat das einen Einfluss auf das eingangs beschriebene Verhalten des Apache.

Vielen Dank bis hierher.

[MSfree]

Ich weiß nicht, ob das auch wichtig ist. Die /var/log/apache2/error.log füllt sich im Sekundentakt mit Einträgen wie diesem

Code: Alles auswählen

[Fri Apr 12 11:22:40.737843 2024] [core:notice] [pid 106838] AH00052: child pid 106904 exit signal Segmentation fault (11)

Das heißt. daß Apache mit einer Speicherschutzverletzung abstürzt. Ich denke, daß das durchaus wichtig ist.

Code: Alles auswählen

# apache2 -X

Ist das die Ausgabe deines Servers? Oder ist das von irgendwoher aus dem Internet kopiert?

[oln]

Wie sind die Berechtigungen der Dateien?
Die Datei envvars muss -rw-r--r-- haben.

[JamesByrnes]

Code: Alles auswählen

# apache2 -X

Ist das die Ausgabe deines Servers? Oder ist das von irgendwoher aus dem Internet kopiert?

Das habe ich u.a. hier gesehen https://serverfault.com/questions/66580 ... g-fault-11, https://unix.stackexchange.com/question ... n-fault-11.

[oln]

Hast du mal apache2ctl configtest ausgeführt?

[JamesByrnes]

Wie sind die Berechtigungen der Dateien?
Die Datei envvars muss -rw-r--r-- haben.

Die sind stimmig:

Code: Alles auswählen

ll /etc/apache2/envvars 
-rw-r--r-- 1 root root 1782  9. Jun 2022  /etc/apache2/envvars

Nur am Rande, der Server ist ganz frisch installiert, nur die Configs und Daten sind rüber gezogen wurden.

[JamesByrnes]

Hast du mal apache2ctl configtest ausgeführt?

Sagte ich doch, ja.

[MSfree]

Das habe ich u.a. hier gesehen https://serverfault.com/questions/66580 ... g-fault-11, https://unix.stackexchange.com/question ... n-fault-11.

Segfaults könne viele unterschiedliche Ursachen haben, danach zu googeln, ist wenig zielführend. Das, was da bei stackexchange steht, muß nicht unbedingt etwas mit deinem Problem zu tun haben.

[JamesByrnes]

Segfaults könne viele unterschiedliche Ursachen haben, danach zu googeln, ist wenig zielführend. Das, was da bei stackexchange steht, muß nicht unbedingt etwas mit deinem Problem zu tun haben.

Dann versuchen wir es doch einzukreisen.
- Server ist ganz frisch mit Debian 12 installiert.
- Die Vhosts sind übernommen wurden.
- Letsencrypt-Zertifikate wurden übernommen.
- Die Config-Dateien aus /etc wurden übernommen
- externe IP-Adresse ist unverändert geblieben.
- /srv/www wurde komplett übernommen.

Was könnte dann zu den Segfaults bei einem neuen Apache führen?

[MSfree]

Was könnte dann zu den Segfaults bei einem neuen Apache führen?

Segfaults sollten überhaupt nicht passieren, in fast allen Fällen sind es Programmierfehler. Wenn ein Programm z.B. auf Daten im RAM zugreifen will, die es nicht gibt, oder nicht mehr gibt, gibt es ein Segfault. Ich sehe allerdings ein, daß dir die Erklärung wahrscheinlich im Moment nicht bei der Problemlösung hilft.

Der Unterschied zwischen systemctl restart apache2 und systemctl reload apache2 ist, daß restart einen bereits laufenden apache2 beendet und dann komplett neu startet. relaod weist einen laufenden apache2 an, seine Komnfigurationsdaten zu verwerfen und neu einzulesen, der laufende Prozeß wird dabei nicht beendet und neu gestartet. reload ist schneller, könnte aber hier zu deinem Problem führen, wenn apache2 bedingt durch einen Programmierfehler sich nicht sauber aufräumt.

[JamesByrnes]

Was wäre dann eine Lösung? Ein Apache2-Paket älter das Aktuelle installieren oder Testing-Pakete?

[MSfree]

Was wäre dann eine Lösung?

Wenn restart bzw. start funktioniert, kannst du es doch erstmal bei der aktuellen Version belassen?

Grundsätzlich wäre aber ein Bugreport sinnvoll, wenn reload reproduzierbar mit Segfault aussteigt.

[oln]

Also ich glaube nicht an einen Bug. Warum? Weil hier mehrere Server so laufen.
Dein Sync von der alten Kiste hat bestimmt irgend welche Rechte an Dateien und Ordnern verbogen.
Ein permanentes Segfault bei einem Child ist nicht normal. Da würde ich ansetzen.

Überprüfe die Möglichkeit des Zugriffs auf /srv/www durch www-data als User(Warum nicht DebianPath /var/www/).
Überprüfe die Rechte auf /etc/apache2 durch www-data als User.
Denke das dort irgenwo der Fehler her kommt.

[MSfree]

Also ich glaube nicht an einen Bug.

Ein Segfault ist fast immer durch Programmierfehler bedingt, also ist es hier schon fast sicher ein Bug. Und selbst, wenn Berechtigungsprobleme ein Segfault verursachen, dann wurde eine Situation im Programm, z.B. Datei kann nicht geöffnet werden, nicht korrekt behandelt. Programme dürfen in so einer Situation einfach nicht mit Segfault abstürzen. Eine Fehlermeldung und ein sauberer Exit wäre die richtige Methode, wenn man es nicht anders abfangen kann.

In seltenen Fällen, können Segfaults natürlich auch durch Hardwarefehler hervorgerufen werden, z.B. durch defektes RAM.

[JamesByrnes]

Also ich glaube nicht an einen Bug.

Ein Segfault ist fast immer durch Programmierfehler bedingt, also ist es hier schon fast sicher ein Bug. Und selbst, wenn Berechtigungsprobleme ein Segfault verursachen, dann wurde eine Situation im Programm, z.B. Datei kann nicht geöffnet werden, nicht korrekt behandelt. Programme dürfen in so einer Situation einfach nicht mit Segfault abstürzen. Eine Fehlermeldung und ein sauberer Exit wäre die richtige Methode, wenn man es nicht anders abfangen kann.

In seltenen Fällen, können Segfaults natürlich auch durch Hardwarefehler hervorgerufen werden, z.B. durch defektes RAM.

Nun das würde aber heißen, dass etliche Installationen alleine bei Debian 12 betroffen wären und das wäre längst hier publik. Das mit dem Hardwarefehler schließe ich auch aus, da das eine Proxmox-VM ist. Und der Root-server selber ist 1/2 Jahr alt, bzw. dann müssten die anderen VMs ja Segfaults aufweisen.

[JamesByrnes]

Überprüfe die Möglichkeit des Zugriffs auf /srv/www durch www-data als User(Warum nicht DebianPath /var/www/).
Überprüfe die Rechte auf /etc/apache2 durch www-data als User.
Denke das dort irgenwo der Fehler her kommt.

/var/www habe ich nicht genommen, weil unter /srv eine separate Disk liegt, mit extra viel Platz. Außerdem sollten hier ja Daten für Serverprozesse abgelegt werden. Vor allem Letzteres ist der Hauptgrund.

Ansonsten liebäugle ich eher damit, den Apache2 auf der Maschine komplett neu zu installieren. Vielleicht bringt das etwas.
Vielen Dank für die ausführlichen Gedanken hier.

Grüße
James

[MSfree]

Nun das würde aber heißen, dass etliche Installationen alleine bei Debian 12 betroffen wären und das wäre längst hier publik.

Es sei denn, du hast eine Konstellation, die sonst noch keiner genutzt hat. Dann wärst du der erste, dem es auffällt.

[JamesByrnes]

Also, ich habe folgenden Befehl abgesetzt

Code: Alles auswählen

dpkg  --force-depends --purge apache2 apache2-bin apache2-data apache2-utils

und das Apache2-Verzeichnis komplett gelöscht - inklusive Backup desselben.
Und danach habe ich nach einem "apt-get update" den Apache2-Server neu installiert.

Bis jetzt sind die Segfault-Meldungen in der error.log tauchen jetzt nicht mehr auf. Jetzt werde ich mal step-by-step die Webseiten wieder zu laufen bringen.

Viele Grüße und Dankeschön

James