Crowdsec on OPNsense and weird behaviour with notification-http process

[Finance6104]

I don’t know if this is a result of my misconfiguration or something else, but I found a behaviour that is really weird.

I have a multi-server setup. My router (OPNsense box) is running as LAPI and other servers are running as agents. Connections are over HTTPS (self-signed certs). Everything is working perfectly fine, no issues.

However, when I enable the notifications to my Discord server on OPNsense, things get weird.

  PID USERNAME    THR PRI NICE   SIZE    RES STATE    C   TIME    WCPU COMMAND
42842 root         18  20    0  1630M   282M kqread   4   2:50   0.42% crowdsec
14354 root          9  20    0  1568M  1046M nanslp   5   1:26   0.75% suricata
76335 root         16  20    0  1377M   100M uwait    4   0:07   0.44% crowdsec
64506 root         11  20    0  1211M    62M uwait    4   0:01   0.00% crowdsec-firewall-b
59065 nobody       11  21    0  1209M    19M uwait    0   0:00   0.00% notification-http
55402 nobody       11  21    0  1209M    18M uwait    4   0:00   0.00% notification-http
63379 nobody       11  21    0  1209M    18M uwait    1   0:00   0.00% notification-http
77672 nobody       11  24    0  1209M    18M uwait    0   0:00   0.00% notification-http
61765 nobody       11  21    0  1209M    18M uwait    0   0:00   0.00% notification-http
65210 nobody       11  23    0  1209M    18M uwait    5   0:00   0.00% notification-http
65990 nobody       11  21    0  1209M    19M uwait    0   0:00   0.00% notification-http
66380 nobody       12  24    0  1209M    19M uwait    0   0:00   0.00% notification-http
75519 nobody       11  26    0  1209M    19M uwait    5   0:00   0.00% notification-http
71378 nobody       12  21    0  1209M    19M uwait    0   0:00   0.00% notification-http
57563 nobody       11  21    0  1209M    18M uwait    5   0:00   0.00% notification-http
61067 nobody       12  21    0  1209M    18M uwait    3   0:00   0.00% notification-http
60579 nobody       12  21    0  1209M    18M uwait    2   0:00   0.00% notification-http
78313 nobody       12  24    0  1209M    18M uwait    3   0:00   0.00% notification-http
70619 nobody       11  21    0  1209M    18M uwait    4   0:00   0.00% notification-http
62619 nobody       11  21    0  1209M    18M uwait    5   0:00   0.00% notification-http
30901 nobody       12  23    0  1209M    18M uwait    3   0:00   0.00% notification-http
65066 nobody       11  20    0  1209M    18M uwait    4   0:00   0.00% notification-http
64196 nobody       11  23    0  1209M    18M uwait    1   0:00   0.00% notification-http
76615 nobody       12  26    0  1209M    18M uwait    2   0:00   0.00% notification-http
53645 nobody       12  21    0  1209M    18M uwait    2   0:00   0.00% notification-http
55127 nobody       12  21    0  1209M    18M uwait    4   0:00   0.00% notification-http
66034 nobody       11  21    0  1209M    18M uwait    5   0:00   0.00% notification-http
57947 nobody       11  21    0  1209M    18M uwait    1   0:00   0.00% notification-http
40760 nobody       11  20    0  1209M    18M uwait    0   0:00   0.00% notification-http
53835 nobody       11  21    0  1209M    18M uwait    0   0:00   0.00% notification-http
71633 nobody       11  21    0  1209M    18M uwait    0   0:00   0.00% notification-http
54576 nobody       11  21    0  1209M    18M uwait    4   0:00   0.00% notification-http
38065 nobody       12  23    0  1209M    18M uwait    4   0:00   0.00% notification-http
63007 nobody       11  21    0  1209M    18M uwait    5   0:00   0.00% notification-http
42854 nobody       12  20    0  1209M    18M uwait    3   0:00   0.00% notification-http
61630 nobody       11  28    0  1209M    18M uwait    3   0:00   0.00% notification-http
72571 nobody       12  21    0  1209M    18M uwait    4   0:00   0.15% notification-http

For some reason the notification-http process keeps replicating. This doesn’t stop in any point and after a few hours router runs out of memory. Notifications work normally the whole time.

I have configured the LAPI to run on port 8081 because I couldn’t get HTTPS to work with the default LAPI port (kept getting errors that 8080 only responded HTTP instead of the asked HTTPS). Could this change cause this issue?

[mmetc]

Hi,

could you test this

# fetch -o /usr/local/etc/rc.d/crowdsec https://github.com/crowdsecurity/plugins/releases/download/crowdsec-1.6.3-2-hotfix/crowdsec

It should take care of notification plugins and any other process management issue.

Thanks

[thibault]

Hello, please see:

[BUG] OPNSense - 24.7.5 & Crowdsec 1.6.3

Hello, CrowdSec 1.6.3, 1.6.3-1 distributed with OpnSense 24.7.5 introduced a bug in the service stop feature, leading to various issues: Service restart will get stuck (as CrowdSec doesn’t manage to stop) OpnSense and CrowdSec upgrade process will get stuck (when trying to shutdown CrowdSec) Notification plugins can end up orphaned and consume an excessive amount of memory Version 1.6.3-2 fixes the issue but currently requires manual intervention, described here: # fetch -o /usr/local/etc/…

[Finance6104]

This seems to have fixed this issue and some other weird behaviour that was probably related.

The notification issue was caused by one agent that had it’s notifications still enabled. This caused those orphaned notification processes, but I am glad to hear this was also hotfixed.

I also had some weird issues when changing settings and restarting Crowdsec the logs would say that the port (8081) was taken by some other process. This was probably caused by the fact that Crowdsec failed to properly close before restarting. This seems to be fixed aswell, as you said.

[brott8]

Hello,

I appear to be hitting the same failure described in this prior topic:

However, this is occurring on a much newer installation.

Environment:

• OPNsense with os-crowdsec 1.0.12
• crowdsec 1.8.1
• crowdsec-firewall-bouncer 0.0.34_7
• FreeBSD
• CrowdSec / cscli version: v1.8.1-909b515
• Build date: 2026-09-14
• Go version: 1.26.8

I have Pushover configured as the only active notification:

Active  Name      Type  Profile name
✔️       pushover  http  default_ip_remediation

All other default notifications, including http_default, are inactive.

Pushover delivery itself works. A direct curl POST to the Pushover API succeeds, and cscli notifications test pushover successfully delivers a notification.

The problem is that notification-http processes accumulate rapidly. They do not exit and eventually exhaust memory. Each process is approximately 24 MiB, so hundreds of orphaned workers consume several GiB.

Example:

ps -axo pid,ppid,rss,etime,command | grep '[n]otification-http'

shows a large number of entries like:

PID    PPID  RSS    ELAPSED  COMMAND
19       1  24576   25:44    /usr/local/lib/crowdsec/plugins/notification-http
196      1  24164   29:41    /usr/local/lib/crowdsec/plugins/notification-http
14515    1  24804   02:14    /usr/local/lib/crowdsec/plugins/notification-http
62097    1  24080   00:16    /usr/local/lib/crowdsec/plugins/notification-http

All leaked instances have PPID 1.
Restarting CrowdSec alone does not clean up the orphaned instances.

This looks very similar to the old OPNsense service-stop issue fixed by the CrowdSec 1.6.3-2 hotfix, where notification plugins could be orphaned during service stop/restart. I have not applied that old hotfix because this system runs CrowdSec 1.8.1.

Questions:

1. Is this a known regression in the OPNsense/FreeBSD CrowdSec service script or plugin process handling?
2. Is there a current replacement for the old 1.6.3-2 hotfix that is compatible with CrowdSec 1.8.1?
3. What additional logs or diagnostics would be useful?

As a temporary workaround, I have disabled the Pushover notification profile. CrowdSec itself remains enabled and memory is now under control.