"
Hallo zusammen,
ich habe auf meinem System massive Stabilitätsprobleme mit dem Squid Proxy.
Meine Umgebung:
OPNsense: 25.1.8_1-amd64
FreeBSD: 14.2-RELEASE-p3
OpenSSL: 3.0.16
Squid: Version 6.12 (über OPNsense integriert)
Problembeschreibung
Squid startet nach einem frischen Reboot EINMAL mit OPNsense-Standardkonfiguration korrekt.
Jeder Neustart des Squid-Dienstes über die OPNsense-GUI (bzw. auch per Shell mit service squid start) führt zu einem Segmentation fault.
Gleiches gilt für squid -z sowie für den Startversuch im Debug-Modus.
In den Systemlogs taucht nach jedem Absturz:
pid XXXXX (squid), jid 0, uid 100: exited on signal 11 (no core dump - bad address)
Besonders auffällig:
Die Konfiguration enthält automatisch erzeugt die Zeile
cache_dir rock /var/squid/cache 512
OPNsense-GUI bietet keine Option, auf ufs als Cache-Backend umzuschalten.
Manuelle Änderungen an /usr/local/etc/squid/squid.conf werden nach Aktionen in der GUI wieder überschrieben.
Rechte aller relevanten Verzeichnisse (/var/squid/cache, /var/log/squid, /var/run/squid) wurden mehrfach auf den User squid (UID 100) gesetzt.
Typische Logausgabe (beim Absturz):
Set Current Directory to /var/squid/cache
Segmentation fault
oder (bei manuellem Debug-Start nach Neustart):
FATAL: Ipc::Mem::Segment::create failed to shm_open(/var/run/squid/cf__metadata.shm): (17) File exists
Segmentation fault
Ein Sauberer Reboot und ein "frischer" Start durch OPNsense erzeugt einmalig laufende Squid-Prozesse. Ein Neustart des Dienstes über die GUI bringt den Fehler unmittelbar zurück.
Was habe ich bereits erfolglos probiert?
Rechte von /var/squid/cache, /var/log/squid und /var/run/squid auf squid:squid gesetzt und rekursiv 750.
Manuelles Löschen aller .shm, .pid und Cache-Dateien.
Testweise Minimalkonfiguration mit explizitem cache_effective_user squid und cache_effective_group squid (führt auch zu Segfault mit rock, aber funktioniert mit ufs – wird aber wieder überschrieben).
Test, ob manuell als User squid im "sauberen" Kontext gestartet (mit env-Reset, Home auf /var/squid): Fehler bleibt.
Einzige zuverlässige temporäre Lösung ist ein Systemneustart – bis zum nächsten Dienst- oder Konfigurations-Reload.
Hardware-Defekte sind höchst unwahrscheinlich (keine sonstigen Instabilitäten, Speicher- und Plattenplatz reichlich vorhanden).
Fragen an die Community:
1. Ist dieser Fehler mit cache_dir rock und Segmentation Fault unter OPNsense 25.1.8_1 und FreeBSD 14.2 / Squid 6.12 noch anderen Anwendern/Diensten bekannt?
2. Gibt es einen Weg, ausschließlich über die OPNsense-GUI das Caching auf ufs umzustellen?
3. Existiert ein offizieller Workaround oder ein geplanter Patch im OPNsense-Projekt, mit dem Squid zuverlässig ohne Segfault genutzt werden kann (auch bei Dienstneustart)?
4. Weitere Debug-/Workaround-Tipps? Muss man an den IPC-/Shared-Memory-Einstellungen von FreeBSD (oder Tunables) etwas anpassen?
5. Ist ein Squid-Downgrade unter OPNsense möglich/sinnvoll, um rock-Backend-Problemen unter FreeBSD 14.2 auszuweichen?
Danke für jeden Hinweis
ich habe auf meinem System massive Stabilitätsprobleme mit dem Squid Proxy.
Meine Umgebung:
OPNsense: 25.1.8_1-amd64
FreeBSD: 14.2-RELEASE-p3
OpenSSL: 3.0.16
Squid: Version 6.12 (über OPNsense integriert)
Problembeschreibung
Squid startet nach einem frischen Reboot EINMAL mit OPNsense-Standardkonfiguration korrekt.
Jeder Neustart des Squid-Dienstes über die OPNsense-GUI (bzw. auch per Shell mit service squid start) führt zu einem Segmentation fault.
Gleiches gilt für squid -z sowie für den Startversuch im Debug-Modus.
In den Systemlogs taucht nach jedem Absturz:
pid XXXXX (squid), jid 0, uid 100: exited on signal 11 (no core dump - bad address)
Besonders auffällig:
Die Konfiguration enthält automatisch erzeugt die Zeile
cache_dir rock /var/squid/cache 512
OPNsense-GUI bietet keine Option, auf ufs als Cache-Backend umzuschalten.
Manuelle Änderungen an /usr/local/etc/squid/squid.conf werden nach Aktionen in der GUI wieder überschrieben.
Rechte aller relevanten Verzeichnisse (/var/squid/cache, /var/log/squid, /var/run/squid) wurden mehrfach auf den User squid (UID 100) gesetzt.
Typische Logausgabe (beim Absturz):
Set Current Directory to /var/squid/cache
Segmentation fault
oder (bei manuellem Debug-Start nach Neustart):
FATAL: Ipc::Mem::Segment::create failed to shm_open(/var/run/squid/cf__metadata.shm): (17) File exists
Segmentation fault
Ein Sauberer Reboot und ein "frischer" Start durch OPNsense erzeugt einmalig laufende Squid-Prozesse. Ein Neustart des Dienstes über die GUI bringt den Fehler unmittelbar zurück.
Was habe ich bereits erfolglos probiert?
Rechte von /var/squid/cache, /var/log/squid und /var/run/squid auf squid:squid gesetzt und rekursiv 750.
Manuelles Löschen aller .shm, .pid und Cache-Dateien.
Testweise Minimalkonfiguration mit explizitem cache_effective_user squid und cache_effective_group squid (führt auch zu Segfault mit rock, aber funktioniert mit ufs – wird aber wieder überschrieben).
Test, ob manuell als User squid im "sauberen" Kontext gestartet (mit env-Reset, Home auf /var/squid): Fehler bleibt.
Einzige zuverlässige temporäre Lösung ist ein Systemneustart – bis zum nächsten Dienst- oder Konfigurations-Reload.
Hardware-Defekte sind höchst unwahrscheinlich (keine sonstigen Instabilitäten, Speicher- und Plattenplatz reichlich vorhanden).
Fragen an die Community:
1. Ist dieser Fehler mit cache_dir rock und Segmentation Fault unter OPNsense 25.1.8_1 und FreeBSD 14.2 / Squid 6.12 noch anderen Anwendern/Diensten bekannt?
2. Gibt es einen Weg, ausschließlich über die OPNsense-GUI das Caching auf ufs umzustellen?
3. Existiert ein offizieller Workaround oder ein geplanter Patch im OPNsense-Projekt, mit dem Squid zuverlässig ohne Segfault genutzt werden kann (auch bei Dienstneustart)?
4. Weitere Debug-/Workaround-Tipps? Muss man an den IPC-/Shared-Memory-Einstellungen von FreeBSD (oder Tunables) etwas anpassen?
5. Ist ein Squid-Downgrade unter OPNsense möglich/sinnvoll, um rock-Backend-Problemen unter FreeBSD 14.2 auszuweichen?
Danke für jeden Hinweis
