[Bug 284377] security/suricata: fix suricata-update baked in paths to JustWork on FreeBSD
Date: Wed, 27 May 2026 14:23:36 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284377
yds <yds@Necessitu.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #270963|0 |1
is obsolete| |
--- Comment #7 from yds <yds@Necessitu.de> ---
Created attachment 271253
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=271253&action=edit
fix suricata-update baked in paths to JustWork on FreeBSD
patch updated to apply clean on top of the current 8.0.5 port.
this patch adds `@dir /var/cache/suricata/sgh` to pkg-plist and configures the
pkg to use the path by default in `suricata.yaml.sample`:
```
detect:
sgh-mpm-context: auto
sgh-mpm-caching: yes
sgh-mpm-caching-path: /var/cache/suricata/sgh
```
getting this setting right made a night-and day difference when rebooting with
suricata enabled.
/without/ sgh-mpm-caching-path properly configured suricata re-compiles all the
HyperScan filters every time suricata is restarted which can take more than 15
minutes on a 8-core Xeon at 100% CPU usage.
/after/ setting `sgh-mpm-caching-path: /var/cache/suricata/sgh` there's no 100%
CPU usage spike when launching suricata. now the CPU spike happens only during
the nightly suricata-update cronjob run and there's no need for suricata to
recompile anything every single time after a restart.
FWIW, I set my suricata-update cronjob to run about 30 minutes after midnight
-- seems like a quiet enough time when the CPU is not being tasked with any
other chores. based on the timestamps in /var/cache/suricata/sgh/ suricata is
typically done compiling the updated HyperScan filters by 45 minutes after
midnight.
--
You are receiving this mail because:
You are the assignee for the bug.