Issues with Reboot / Power Off from OPNSense GUI running in Unraid VM.

[mrzaz]

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

[Patrick M. Hausen]

Is ACPI enabled for your VM?

[mrzaz]

Is 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

[wincent]

Has your OPNsense installed the os-vmware plugin?

[mrzaz]

Has 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

[annoniempjuh]

...
AFAIK there is no QEMU vm support in OpnSense.
...

os-qemu-guest-agent is under community plugins ;)

[wincent]

Nope, as this is not VMWare but rather QEMU under Unraid.

Sorry, my mistake, if your VM using UEFI not legacy BIOS, try this:

Code Select Expand

sysctl hw.efi.poweroff=0
If this works, add to System->Settings->Tunables
OR

Code Select Expand

echo "hw.efi.poweroff=0" >> /etc/sysctl.conf


[nero355]

...
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 :)

[EmilyLewis]

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 στιγμή έχει ένταση.

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.

[mrzaz]

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

[mrzaz]

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

[mrzaz]

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.

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

[wincent]

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

[mrzaz]

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

[wincent]

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