# Crowdsec on OPNsense and weird behaviour with notification-http process

**URL:** <https://discourse.crowdsec.net/t/crowdsec-on-opnsense-and-weird-behaviour-with-notification-http-process/2033>\
**Category:** crowdsec\
**Created:** [October 1, 2024, 6:55am UTC](https://discourse.crowdsec.net/t/crowdsec-on-opnsense-and-weird-behaviour-with-notification-http-process/2033 "2024-10-01T06:55:42Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![Finance6104](https://avatars.discourse-cdn.com/v4/letter/f/df705f/32.png) [@Finance6104](https://discourse.crowdsec.net/u/Finance6104)\
**Post date:** [October 1, 2024, 6:55am UTC](https://discourse.crowdsec.net/t/crowdsec-on-opnsense-and-weird-behaviour-with-notification-http-process/2033/1 "2024-10-01T06:55:42Z")

</div>

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.

```auto
  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?

---

<div class="post-metadata">

**Author:** ![mmetc](https://dub1.discourse-cdn.com/flex013/user_avatar/discourse.crowdsec.net/mmetc/32/233_2.png) [@mmetc](https://discourse.crowdsec.net/u/mmetc)\
**Post date:** [October 7, 2024, 1:36pm UTC](https://discourse.crowdsec.net/t/crowdsec-on-opnsense-and-weird-behaviour-with-notification-http-process/2033/2 "2024-10-07T13:36:41Z")

</div>

Hi,

could you test this

```auto
# 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

---

<div class="post-metadata">

**Author:** ![thibault](https://dub1.discourse-cdn.com/flex013/user_avatar/discourse.crowdsec.net/thibault/32/2_2.png) [@thibault](https://discourse.crowdsec.net/u/thibault)\
**Post date:** [October 8, 2024, 1:42pm UTC](https://discourse.crowdsec.net/t/crowdsec-on-opnsense-and-weird-behaviour-with-notification-http-process/2033/3 "2024-10-08T13:42:55Z")

</div>

Hello, please see:

> [@\[BUG\] OPNSense - 24.7.5 & Crowdsec 1.6.3](https://discourse.crowdsec.net/t/bug-opnsense-24-7-5-crowdsec-1-6-3/2057):
>
> 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](https://github.com/crowdsecurity/plugins/releases/tag/crowdsec-1.6.3-2-hotfix): # fetch -o /usr/local/etc/…

---

<div class="post-metadata">

**Author:** ![Finance6104](https://avatars.discourse-cdn.com/v4/letter/f/df705f/32.png) [@Finance6104](https://discourse.crowdsec.net/u/Finance6104)\
**Post date:** [October 8, 2024, 2:58pm UTC](https://discourse.crowdsec.net/t/crowdsec-on-opnsense-and-weird-behaviour-with-notification-http-process/2033/4 "2024-10-08T14:58:07Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![brott8](https://dub1.discourse-cdn.com/flex013/user_avatar/discourse.crowdsec.net/brott8/32/1454_2.png) [@brott8](https://discourse.crowdsec.net/u/brott8)\
**Post date:** [September 24, 2026, 6:35am UTC](https://discourse.crowdsec.net/t/crowdsec-on-opnsense-and-weird-behaviour-with-notification-http-process/2033/5 "2026-09-24T06:35:19Z")

</div>

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:

```auto
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:

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

```

shows a large number of entries like:

```auto
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.