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
Hey @SirBoerky
bei der Lösung meines Problems bin ich auf deinen Post hier gestoßen.
Bei meinem Problem ist das Zusammenspiel os-squid & os-cicap fehlerhaft gewesen.
> https://forum.opnsense.org/index.php?topic=48208.0
Aber auch bei mir hat squid erst ab Version 25.7.1 das Problem mit dem "Segmentation fault".
Jedoch die 'alte' config aus der 25.1 Version startet squid am Ende zuverlässig.
Ansatz ist:
Version ausssuchen auf:
https://pkg.opnsense.org/FreeBSD:14:amd64/25.1/MINT/
Web Dashboard
[ Version ]
System > Firmware > Settings
# advanced mode
# Flavour > (custom) > 25.1/MINT/{VERSION}/latest/
# Reboot > [x] Always reboot after a successful update
{ Save }
System > Firmware > Status
{ Check for updates }
....
Nach erfolgreicher Konfiguration und Test auf die aktuelle Version (heut: 25.7.1) zu aktualisieren.
Hoffe ich konnte dir helfen, so dass der Service deiner Firewall nutzbar ist.
Moin...
Was du erfolglos probiert hast:
.shm, .pid, .ipc, Cachedateien gelöscht >Fehler bleibt
Rechte korrekt gesetzt (squid:squid 750)>Fehler bleibt
cache_effective_user/group gesetzt > ufs funktioniert, rock stürzt ab
Minimalkonfiguration> Segfault bleibt bei rock
Start als squid im isolierten Kontext>Fehler tritt trotzdem auf
Neustart des Systems> Fehler temporär weg
Die Tatsache, dass ufs funktioniert, aber rock zum Segfault bei SHM führt :
Rock-Store nutzt aggressive Shared Memory (z. B. für Metadaten oder Performanceoptimierung)
squid versucht, SHM über POSIX (shm_open) zu erstellen
Wenn squid den SHM-Bereich nicht korrekt freigeben oder übernehmen kann, bleibt die Datei bestehen, kann aber nicht neu verwendet werden, wenn:
-Der SHM-Key/Name immer gleich ist (cf__metadata.shm)
-Die Datei von einem abgestürzten Prozess nicht ordnungsgemäß entfernt wurde
-FreeBSD (oder das Jail/Chroot/OPNsense) einen "Zombie"-SHM-Bereich zurücklässt
Bitte mal folgenden Check:
POSIX SHM-Cleanup im Kernel + sysctl-Einstellungen prüfen
Aktive SHM-Segmente prüfen
ipcs -m
ODER für POSIX SHM:
ls /dev/shm
ODER (FreeBSD-typisch):
sysctl kern.ipc | grep shm
Du wirst kein File in /dev/shm sehen, aber ipcs könnte noch verwendete Segmente zeigen
Systemweite SHM-Grenzen prüfen
sysctl kern.ipc.shmseg
sysctl kern.ipc.shmmni
sysctl kern.ipc.shmmax
Wenn z. B. viele SHM-Segmente zu schnell erzeugt werden, kann es sein, dass Squid keine neuen erstellen darf,
selbst wenn die alte Datei gelöscht ist.
Temp Lösung:
Grenzwerte erhöhen
sysctl kern.ipc.shmseg=1024
sysctl kern.ipc.shmmni=1024
sysctl kern.ipc.shmmax=134217728
Für permanent: in /boot/loader.conf oder /etc/sysctl.conf eintragen
Force-Unlink POSIX SHM (advanced!)
Wenn SHM intern "hängt", reicht das Löschen der Datei nicht aus. Du kannst stattdessen:
VORSICHT: Nur verwenden, wenn du weißt, dass nichts anderes shared memory nutzt
ipcrm -M 0x<key>
Die Key-ID bekommst du ggf. aus:
ipcs -m
Fallback Rock-Store deaktivieren (vorübergehend)
Falls die SHM-Probleme dauerhaft auftreten, ist es u. U. sinnvoll, temporär auf ufs umzusteigen
cache_dir ufs /var/squid/cache 5120 16 256
Das ist zwar langsamer, aber deutlich weniger fehleranfällig, bis OPNsense/Squid ein Update für rock-Stabilität liefert
Quellen für die Probleme evt.:
Squid läuft in einer Jail / chroot Umgebung, und die SHM-Namespace-Säuberung funktioniert nicht korrekt
Multithreading-Probleme in Verbindung mit rock-Store
Incomplete Patchset bei Squid-OPNsense-Port > ggf. auch Bug in Build-Umgebung
Super & vielen Dank @fw115
für mich als 'Newbie' ist die von mir beschriebene Lösung ganghaft.
Deine Ideen um das Problem in der aktuellen Version am Ende zu patchen ist der korrekte Weg.
Aber; ein Produkt wie OPNsense, soll ja neben jeder Lösung auch Spaß + Erfolge bringen.
In meinem Fall ersetzt es eine alte Lösung im privaten Umfeld mit vielen guten FW-Regeln und Abhängigkeiten.
Es wird der Tag kommen, wenn ich mit meinem Wissen aktiv an den Lösungen arbeiten werde.
Solange bestimmt das Ziel den Weg und eine Lösung (siehe oben) in kürze.
----
OPNsense 25.7.1_1-amd64
FreeBSD 14.3-RELEASE-p1
OpenSSL 3.0.17