Hello,
I had some HW breakdown that led me to temporary run OpnSense as a VM under Unraid.
This works OK as such but have some weird issue seen when I try to start a reboot or shutdown from the Web GUI.
Regardless if I click on Reboot or Power Off nothing happens (apart from web gui saying that it is shutting down)
if I check the console. No messages indicating that the system is about to go down or reboot.
I have waited for a long time but still nothing happens.
If I then, from the console, try to reboot or power off then I could see that it starts to go down as it should.
is there anyone else who have seen this issue ?
Either as VM or on native HW.
Best regards
Dan Lundqvist
Stockholm, Sweden
Is ACPI enabled for your VM?
Quote from: Patrick M. Hausen on June 22, 2026, 09:12:42 PMIs ACPI enabled for your VM?
I think so, but will doublecheck.
However, as I mentioned, it is not that it hangs anywhere in the shutdown, but rather that it does not indicating anything in the console that a shutdown has been initiated and it just stays forever (when selected from webGUI). WebGUI says shutdown in progress, but console says nothing.
BUT, if I select shutdown from the console it immediately starts showing that a shutdown sequence has started and stopping everything and finally shuts down/ powers off.
I do have some issues with Suricata PID takes forever to die but that is a separate topic. 🙂
Best regards
Dan Lundqvist
Has your OPNsense installed the os-vmware plugin?
Quote from: wincent on June 23, 2026, 02:58:09 AMHas your OPNsense installed the os-vmware plugin?
Nope, as this is not VMWare but rather QEMU under Unraid.
AFAIK there is no QEMU vm support in OpnSense.
Regardless, if the power off has stopped working, the power off from console should behave the same or?
It doesn't even try to start shutdown. Like any low level web script to start shutdown.
Basically
/ui/core/reboot
/ui/core/halt
Quote from: mrzaz on June 23, 2026, 10:00:35 AM...
AFAIK there is no QEMU vm support in OpnSense.
...
os-qemu-guest-agent is under community plugins ;)
Quote from: mrzaz on June 23, 2026, 10:00:35 AMNope, as this is not VMWare but rather QEMU under Unraid.
Sorry, my mistake, if your VM using UEFI not legacy BIOS, try this:
sysctl hw.efi.poweroff=0
If this works, add to System->Settings->Tunables
OR
echo "hw.efi.poweroff=0" >> /etc/sysctl.conf
Quote from: annoniempjuh on June 23, 2026, 10:15:31 AMQuote from: mrzaz on June 23, 2026, 10:00:35 AM...
AFAIK there is no QEMU vm support in OpnSense.
...
os-qemu-guest-agent is under community plugins ;)
But it doesn't do anything when you use the OPNsense webGUI to Reboot/Power Off so that doesn't really matter in this case if I have understood the issue correctly :)
The fact that shutdown and reboot work correctly from the console but not from the web GUI makes me think this is less likely to be an ACPI or VM power-management issue and more likely something in the path between the GUI and the underlying system command. If ACPI were the main problem, I would expect both methods to fail in a similar way or at least reach the same point before hanging.
I'd be interested to know whether anything relevant appears in the system log at the exact moment you click Reboot or Power Off in the GUI. If the GUI displays "shutdown in progress" but nothing appears on the console, it almost sounds as if the request is being accepted by the interface but never actually reaching the process responsible for initiating the shutdown. Στο MonsterWin Casino κάθε site monster-wins.gr (https://monster-wins.gr/) στιγμή έχει ένταση.
The suggestion regarding UEFI is still worth testing, though. Virtualized environments sometimes behave differently enough that seemingly unrelated settings end up affecting system control actions in unexpected ways.
Quote from: annoniempjuh on June 23, 2026, 10:15:31 AMQuote from: mrzaz on June 23, 2026, 10:00:35 AM...
AFAIK there is no QEMU vm support in OpnSense.
...
os-qemu-guest-agent is under community plugins ;)
yes, found it. Had forgot to click in the clickbox for community plugins.
My thought was earlier that "wow ho much plugins that had been removed,
but it was just that they had placed them in a separate category. :-)
//Danne
Quote from: nero355 on June 24, 2026, 12:16:30 AMQuote from: annoniempjuh on June 23, 2026, 10:15:31 AMQuote from: mrzaz on June 23, 2026, 10:00:35 AM...
AFAIK there is no QEMU vm support in OpnSense.
...
os-qemu-guest-agent is under community plugins ;)
But it doesn't do anything when you use the OPNsense webGUI to Reboot/Power Off so that doesn't really matter in this case if I have understood the issue correctly :)
Correct. Doing a reboot or power off in GUI, only shows that "reboot" or "shutdown initiated but then nothing happens.
It stays like that forever and nothing happens. As can be seen also in console that zero output that a shutdown
has been initiated and starts killing PIDs and synching filesystem preparing for a shutdown or reboot.
If I then do the exact same procedure, but via the console, then it immediately starts showing signs of shutdown initiated
and finally it shuts down or reboot depending which one I chose.
Have some issues with a stubborn Suricata PID the never kills (or at least take way to long to respond)
but that is a separate issue for another day. :-)
//Danne
Quote from: EmilyLewis on June 24, 2026, 10:55:04 AMThe fact that shutdown and reboot work correctly from the console but not from the web GUI makes me think this is less likely to be an ACPI or VM power-management issue and more likely something in the path between the GUI and the underlying system command. If ACPI were the main problem, I would expect both methods to fail in a similar way or at least reach the same point before hanging.
I'd be interested to know whether anything relevant appears in the system log at the exact moment you click Reboot or Power Off in the GUI. If the GUI displays "shutdown in progress" but nothing appears on the console, it almost sounds as if the request is being accepted by the interface but never actually reaching the process responsible for initiating the shutdown.
The suggestion regarding UEFI is still worth testing, though. Virtualized environments sometimes behave differently enough that seemingly unrelated settings end up affecting system control actions in unexpected ways.
Yes, I totally agree with you that this feels like something else. Not a hanging in shutdown but rather the webgui commands
/ui/core/reboot
/ui/core/halt
that does not trigger the underlying codebase to actually trigger the reboot or halt.
As mentioned, trigger from console works totally fine but not from web-gui.
I am running the latest release 26.1.10.
I will do some testing and see if I could catch anything in any log and get back.
I checked some logs and found a few entries in Web GUI (lighthttpd) log.
2026-06-25T00:12:06 Informational lighttpd 192.168.x.x 192.168.x.x- [25/Jun/2026:00:12:05 +0200] "GET / HTTP/1.1" 302 0 "http://192.168.x.x/ui/core/reboot" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:152.0) Gecko/20100101 Firefox/152.0"
2026-06-25T00:12:06 Informational lighttpd 192.168.x.x 192.168.x.x- [25/Jun/2026:00:12:05 +0200] "GET / HTTP/1.1" 302 0 "http://192.168.x.x/ui/core/reboot" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:152.0) Gecko/20100101 Firefox/152.0"
2026-06-25T00:11:21 Informational lighttpd 192.168.x.x 0 192.168.x.x- [25/Jun/2026:00:11:20 +0200] "POST /api/core/system/reboot HTTP/1.1" 200 15 "http://192.168.x.x/ui/core/reboot" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:152.0) Gecko/20100101 Firefox/152.0"
2026-06-25T00:10:53 Informational lighttpd 192.168.x.x 192.168.x.x - [25/Jun/2026:00:10:52 +0200] "GET /api/core/system/status?path=%2Fui%2Fcore%2Freboot HTTP/1.1" 200 187 "http://192.168.x.x/ui/core/reboot" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:152.0) Gecko/20100101 Firefox/152.0"
and following in audit:
2026-06-25T00:11:21 Informational configd.py action allowed system.reboot for user root
But nothing relevant in system, boot, configd (Backend) log.
I enabled ALL settings for each log.
/Danne
Try running "/usr/local/etc/rc.reboot" in the terminal and see what happens. This is the command that the WebGUI actually executes.
Reboot:
/usr/local/etc/rc.reboot
Shutdown:
/usr/local/etc/rc.halt
Quote from: wincent on June 25, 2026, 04:30:53 AMTry running "/usr/local/etc/rc.reboot" in the terminal and see what happens. This is the command that the WebGUI actually executes.
Reboot:
/usr/local/etc/rc.reboot
Shutdown:
/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
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
Quote from: wincent on June 25, 2026, 10:47:17 AMTry 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
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
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.
Quote from: wincent on June 26, 2026, 03:47:07 AMThis 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