Messages

I have now changed from Divert (IPS) to Netmap (IDS) and let it run for 24-36h and now tried a normal reboot and at least this time it rebooted normally.
Only took a few seconds for suricata PID to stop and continue with rest of the shutdown/reboot.

I will keep this under wrap and test it again in a few days.

If it now is Divert setting that causes it, we need to try to find the culprit.

I will try to revert to Divert (IPS) and see if I could reproduce and then use a bunch of hopefully good commands to debug.

//Dan Lundqvist

Hi Franco,

I am facing the same issue. I discovered when the system tried to reboot on last update to Business 26.4.1.
My hardware is from Deciso: DEC 697
I had to connect into the console and kill suricata manually as it never rebooted for more than 10 minutes.
My suricata configuration is in divert mode. Since this divert mode became available, I have switched from IPS mode to divert mode as it makes more sense to inspect in suricata only what firewall is allowing, in my case, one specific rule, instead of inspecting all traffic.

I tried the same command showed as before, but the result was always the same. hanging when trying to stop suricata.
I didn't try changing the suricata mode back to IPS or IDS, but as far as I remember, I nave never experienced this hanging issue before. I have been using OpnSense for more than 3 years and this is the first time I encountered this hanging behavior. All previous updates was always smooth with no issues or hanging.

Regards,
Jorge

Hi Jorge,
Then at least I am not alone in this. 🙂

Due to HW constraints in my old opnsense machine I did not use Suricata that much but has now enabled it more and that's when I discovered it.

It always hanged when trying to shutdown. Only thing powerfully enough to kill it was -9.

Dan Lundqvist

[/usr/local/bin/suricata]

Hi Franco,

I have again ended up with same issue.
I tried to reboot opnsense from GUI and nothing happens on any stdout.

I then checked if suricata process is running which it does.
root@OPNsense:~ # ps aux | sort -nr -k4 | head -20
root    36693   0.0 24.8 16206888 5196580  -  Ss   Thu21     13:33.69 /usr/local/bin/suricata -D -d 8000 -d 8000 -d 8000 --pidfile /var/run/suricata.pid -c /usr/local/etc/suricata/suricata.yaml
root     9539   0.0 16.0  3698000 3337860  -  S    Thu21     17:14.09 /usr/local/bin/python3 /usr/local/share/maltrail/sensor.py (python3.13)
root    57558   0.0 11.9  2655060 2485608  -  S    Thu21     64:17.87 /usr/local/bin/python3 /usr/local/share/maltrail/sensor.py (python3.13)
root    45012   1.0  2.7  1915168  568444  -  S    Thu21     62:42.00 /usr/local/bin/tailscaled -port 41641 -tun tailscale0 -statedir /var/db/tailscale
root    80262   0.0  0.6   360832  116516  -  I    Thu21      3:27.83 /usr/local/bin/python3 /usr/local/opnsense/scripts/unbound/logger.py (python3.13)

root@OPNsense:~ # more /var/run/suricata.pid
36693

It should have been killed by now as I have waited several minutes.

I tried again in console and gets stuck killing suricata.

The system will reboot. Do you want to proceed? [y/N]: y

>>> Invoking stop script 'beep'
>>> Invoking stop script 'freebsd'
crowdsec_firewall is not running.
crowdsec not running? (check /var/run/crowdsec_daemon.pid).
lldpd not running? (check /var/run/lldpd.pid).
qemu_guest_agent not running? (check /var/run/qemu-ga.pid).
snmpd not running? (check /var/run/net_snmpd.pid).
Stopping suricata.
Waiting for PIDS: 36693

Same issue as before...

Not sure if related but have some issues with swap space so have added a second 2GB swap file.
swap_pager: out of swap space
swp_pager_getswapspace(18): failed

When I managed to clear the situation earlier by doing "/usr/local/etc/rc.d/suricata onestop"
and then it worked OK after reboot ro do another reboot using console.

But now back to hanging suricata. :-|

In system Backend log i found:
2026-06-26T23:48:48   Error   configd.py   Timeout (120) executing : 'ids' restart

Will try once more with /usr/local/etc/rc.d/suricata onestop

Not even that one managed to kill suricata.

root@OPNsense:~ # /usr/local/etc/rc.d/suricata onestop
Stopping suricata.
Waiting for PIDS: 36693

"kill -9 36693" was the only one tough enough to kill it.

I will try to reconfigure from "Divert(IPS) to Netmap(IPS) to see if issue persists.

/Dan Lundqvist

This command "/usr/local/etc/rc.d/suricata onestop" will check the status of Suricata and delete the stale PID file, you previously used `kill` to shut down Suricata abnormally, a PID file may be left behind.
Now try to shut down or reboot OPNsense directly using the webGUI.

Thanks wincent,
I will save that one for the future. 🙂

I think I have kind of found out why it never shuts down or restart from WebGUI.
What is actually happening is the issue I have reported in other thread regarding PID for suricata never ending.

When I do the shutdown from webgui a lot of the shutdown messages is only seen in the session stdout who starts the shutdown which console is not.
To console is only some part of the later printouts that is printed to all stdout.

But as the system gets stuck endlessly waiting for suricata PID to end the shutdown never proceeds.

If I do the shutdown from console then you will see all sdtout including the hanging suricata PID.

Feels like a corner case that will seldom happen but could possibly be added as a robustness to the shutdown/reboot scripts handling suricata PID or any PID in future releases. 🙂

I propose to close this case and handle it through the other thread.

Best
Dan Lundqvist
Stockholm, Sweden

I've looked at the code and it's unclear where Suricata would hang. Has to be in poll() or recvfrom() but both have timeouts and SIGINT/SIGTERM should be properly handled and seen by the application eventually within the span of a second.


Cheers,
Franco

Hi Franco,
Thanks for the reply.
It is quite weird. When the issue was present i got the endless waiting for PID suricata that never end. I had to forcefully kill it for the rest of shutdown/reboot stuff to continue. Also when done from gui you didn't know why it was not shutting down or reboot.

I will keep checking if I stumble on it again.

If I do, do you have any commands to print to try to find what is going on?

Best regards
Dan Lundqvist
Stockholm, Sweden

Can you confirm this only happens with divert? It may be an open file descriptor / socket that the kernel doesn't yield.


Cheers,
Franco

If it happens agen  I will try to check that setting.  I prefer to use Divert in the way that is handled.

Can you confirm this only happens with divert? It may be an open file descriptor / socket that the kernel doesn't yield.


Cheers,
Franco

Feels like it happens intermittent now. I tried one more time from console and then it was able to kill all.
Will try one more time from GUI.  Jupp. now that worked as well.

Must be something hanging that is now cleared somehow.
I will monitor this the comming days to see if it re-appers.

//Dan Lundqvist

I tried the proposed in other thread.

I get the following in the console:
root@OPNsense:~ # /usr/local/etc/rc.d/suricata onestop
Stopping suricata.
Waiting for PIDS: 71649.
root@OPNsense:~ #


and the following in Suricata Logfile:

2026-06-25T20:47:04  Notice  suricata  [100787] <Notice> -- (W-8000) Verdict: Accepted 0, Dropped 0
2026-06-25T20:47:04  Notice  suricata  [100787] <Notice> -- (W-8000) Treated: Pkts 0, Bytes 0, Errors 0
2026-06-25T20:47:04  Notice  suricata  [100786] <Notice> -- (W-8000) Verdict: Accepted 0, Dropped 0
2026-06-25T20:47:04  Notice  suricata  [100786] <Notice> -- (W-8000) Treated: Pkts 0, Bytes 0, Errors 0
2026-06-25T20:47:04  Notice  suricata  [100785] <Notice> -- (W-8000) Verdict: Accepted 0, Dropped 0
2026-06-25T20:47:04  Notice  suricata  [100785] <Notice> -- (W-8000) Treated: Pkts 0, Bytes 0, Errors 0
2026-06-25T20:47:03  Notice  suricata  [100642] <Notice> -- Signal Received. Stopping engine.

So when doing this, it shuts down but when it is done as the part of OpnSense shutdown it just hangs.
or at least it says that.  It never passes the killing of PID for surcata and never continues with rest
of the shutdown procedure.

//Dan Lundqvist

Try running "/usr/local/etc/rc.d/suricata onestop" in the terminal and see what happens and then go and check what's in the "Services -> Intrusion Detection -> Log File"

Code Select Expand

/usr/local/etc/rc.d/suricata onestop

I get the following in the console:
root@OPNsense:~ # /usr/local/etc/rc.d/suricata onestop
Stopping suricata.
Waiting for PIDS: 71649.
root@OPNsense:~ #


and the following in Suricata Logfile:

2026-06-25T20:47:04   Notice   suricata   [100787] <Notice> -- (W-8000) Verdict: Accepted 0, Dropped 0
2026-06-25T20:47:04   Notice   suricata   [100787] <Notice> -- (W-8000) Treated: Pkts 0, Bytes 0, Errors 0
2026-06-25T20:47:04   Notice   suricata   [100786] <Notice> -- (W-8000) Verdict: Accepted 0, Dropped 0
2026-06-25T20:47:04   Notice   suricata   [100786] <Notice> -- (W-8000) Treated: Pkts 0, Bytes 0, Errors 0
2026-06-25T20:47:04   Notice   suricata   [100785] <Notice> -- (W-8000) Verdict: Accepted 0, Dropped 0
2026-06-25T20:47:04   Notice   suricata   [100785] <Notice> -- (W-8000) Treated: Pkts 0, Bytes 0, Errors 0
2026-06-25T20:47:03   Notice   suricata   [100642] <Notice> -- Signal Received. Stopping engine.

So when doing this, it shuts down but when it is done as the part of OpnSense shutdown it just hangs.
or at least it says that.  It never passes the killing of PID for surcata.

//Dan Lundqvist

https://forum.opnsense.org/index.php?topic=52191.msg269089;topicseen#msg269089
Double post or similar but separate problem?

This issue is related to that issue as he mentions there two or three times ;)

Hi, that other topic was really not about this issue and I only casually mentioned it as a side-effect.
But it could possible be the main root why it never shut down as it is hanging waiting for suricata PID to stop but never does unless i brutally kill it.

So question is how to proceed. 

I will try what was proposed and we'll see what happens.

>Try running "/usr/local/etc/rc.d/suricata onestop" in the terminal and see what happens and then go and check what's in the "Services -> Intrusion Detection -> >Log File"
>
>/usr/local/etc/rc.d/suricata onestop

//Dan Lundqvist

https://forum.opnsense.org/index.php?topic=52191.msg269089;topicseen#msg269089
Double post or similar but separate problem?

Yes, I have closed that and keeping this only.
Sorry. Was not sure in which group it was best suited.

//Dan Lundqvist

In which mode is suricata running? IDS, IPS (netmap or divert)?


Cheers,
Franco

- Divert (IPS)
Pattern matcher = Aho-Corasick, "Ken Steele" variant.

//Dan Lundqvist

Dont post the same again in other category.

Sorry about that. Wasn't sure if the problem was for generic OpnSense or IPS specific.
I will remove the duplicate.

//Dan Lundqvist

Try running "/usr/local/etc/rc.reboot" in the terminal and see what happens. This is the command that the WebGUI actually executes.

Reboot:

Code Select Expand

/usr/local/etc/rc.reboot
Shutdown:

Code Select Expand

/usr/local/etc/rc.halt

I did test the thing manually and had a epifani. The system seems to have changed behaviour.

When I do the shutdown from Web GUI OR if i login with SSH to node and issue the reboot using "/usr/local/etc/rc.reboot"
then the output is only seen in that SSH screen stdout BUT NOT in the console screen (which it has done in the past).

And because I have the separate issue that has been reported with hanging PID for suricata preventing shutdown/reboot
to finalize. That could be the reason why I do not see anything in the console when doing reboot from web gui.
Basically shutdown is halted/hanging waiting forever and console does not output shutdown text output and as it hangs
forever then we never see anything in the console and server never goes down. (waiting for kill of suricata to proceed)

I think we put a pause on this topic until I get the hanging suricata PID sorted out. :-)

//Dan Lundqvist

[kill -9 26425]

Hello,
I am running latest 26.1.10 under Unraid VM (QEMU) and a permanent issue that
when doing a reboot or shutdown it is getting stuck trying to kill Suricata forever.

Code Select Expand

root@OPNsense:~ # /usr/local/etc/rc.reboot
>>> Invoking stop script 'beep'
>>> Invoking stop script 'freebsd'
crowdsec_firewall is not running.
Stopping crowdsec.
Waiting for PIDS: 22448.
lldpd not running? (check /var/run/lldpd.pid).
qemu_guest_agent not running? (check /var/run/qemu-ga.pid).
snmpd not running? (check /var/run/net_snmpd.pid).
Stopping suricata.
Waiting for PIDS: 26425

I had it sit for several minutes but still stuck.

I then permanently killed it manually by issuing a separate "kill -9 26425" which then let shutdown to continue.

Code Select Expand

root@OPNsense:~ # /usr/local/etc/rc.reboot
>>> Invoking stop script 'beep'
>>> Invoking stop script 'freebsd'
crowdsec_firewall is not running.
crowdsec not running? (check /var/run/crowdsec_daemon.pid).
lldpd not running? (check /var/run/lldpd.pid).
qemu_guest_agent not running? (check /var/run/qemu-ga.pid).
snmpd not running? (check /var/run/net_snmpd.pid).
Stopping suricata.
Waiting for PIDS: 26425.
Stopping acme_http_challenge.
Waiting for PIDS: 16362.
Stopping flowd.
kill: 6470: No such process
kill: 7055: No such process
Stopping maltrailsensor.
Waiting for PIDS: 91290.
Stopping maltrailserver.
Waiting for PIDS: 88043.
Stopping apcupsd.
kill: 62174: No such process
Stopping flowd_aggregate...done
Stopping monit.
Waiting for PIDS: 85295.
crowdsec not running? (check /var/run/crowdsec_daemon.pid).
crowdsec_firewall is not running.
Stopping tailscaled.
Waiting for PIDS: 44920, 44920.
>>> Invoking stop script 'backup'
>>> Invoking backup script 'captiveportal'
>>> Invoking backup script 'netflow'
>>> Invoking backup script 'rrd'
>>> Invoking stop script 'config'
Shutdown NOW!
shutdown: [pid 90818]

*** FINAL System shutdown message from root@OPNsense.mrzaz.com ***

System going down IMMEDIATELY



*** FINAL System shutdown message from root@OPNsense.mrzaz.com ***

System going down IMMEDIATELY

This is what came in other session where i killed the process

Code Select Expand

root@OPNsense:~ # kill -9 26425
*** FINAL System shutdown message from root@OPNsense.mrzaz.com ***

System going down IMMEDIATELY



*** FINAL System shutdown message from root@OPNsense.mrzaz.com ***

System going down IMMEDIATELY

I have tried this several times at various times and get the same issue everytime. 100% failure.
I do have the "os-qemu-guest-agent" installed/running.

Does anyone else having same issue ?
Any idea of any workaround I could test ?