Squid 6.12 Segfault beim Start/Neustart auf OPNsense 25.1.8_1

[SirBoerky]

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

[monateng]

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:

Code Select Expand

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.

[fw115]

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