Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - ubu

#1
26.1 Series / samplicate pegging cpu
Today at 04:31:33 PM
I am very new to opnsense.
Environment
OPNsense 26.1.4 (amd64)
Hardware: HP Pavilion tower, AMD A12-9800 CPU
NICs: igc0 (WAN), igc1 (LAN), re0 (DMZ)

Problem
samplicate is running at 100% CPU continuously. It was configured with two NetFlow destinations (127.0.0.1:2055 and 127.0.0.1:2056) but nothing is actually consuming data on those ports — sockstat confirms nothing is listening on 2056 and only samplicate itself is on 2055.

Reproduction steps
Any attempt to stop samplicate causes an instant silent reboot loop that requires restoring a config backup to recover. Attempts made:
— GUI: Clearing NetFlow destinations and hitting Apply
— CLI: service netflow stop
— CLI: kill <pid>
— CLI: ngctl shutdown ksocket_netflow_igc0: then ngctl shutdown netflow_igc0: then kill <pid>
All result in an immediate reboot loop. System log captures nothing before the reboot — the kernel appears to die before it can write to disk.

Diagnostics
— /var/crash/ is empty — no crash dumps generated
— dmesg shows no panic or fatal entries
— monit is not watching samplicate (monit summary shows only System and RootFs)
— samplicate is launched via daemon wrapper by /usr/local/etc/rc.d/netflow
— netflow stop uses kill -9 on samplicate then ngctl shutdown on netflow nodes
— UPS is healthy (CyberPower 1350VA, 100% charge, OL status)
— No os-netflow, os-insight, or os-ntopng plugins installed — NetFlow is OPNsense core

Current netflow.conf

netflow_interfaces="igc0"
netflow_egress_only="igc0"
netflow_version="9"
netflow_int_destination="127.0.0.1:2055"
netflow_destinations=" 127.0.0.1/2055  127.0.0.1/2056 "
netflow_active_timeout=1800
netflow_inactive_timeout=15
Question
Is this a known issue with netgraph + samplicate on this kernel version? Is there a safe way to disable NetFlow/samplicate without triggering a kernel panic? Is there a way to enable crash dumps to capture the panic for a proper bug report?

Any help appreciated. Happy to run additional diagnostics.