[Bug 284377] security/suricata: fix suricata-update baked in paths to JustWork on FreeBSD

From: <bugzilla-noreply_at_freebsd.org>
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.