The upgrade has finished and your device is being rebooted at the moment, please

[EricPerl]

See reply #14 from Patrick. The easiest is via the services widget on the dashboard IMO.

Only you can decide if Suricata is right for you...

[EricPerl]

how do I free space, no idea what could be using so much

Also, if you have not sorted your full disk already:

Code Select Expand

root@OPNsense:/ # du -shx /* | sort -rh | headthen you can drill down in the biggest offenders...

[gillbot]

There was no full disk, I misread the indicator and I thought it was 1% free but it was only 1% full.

Using the widget from the dashboard doesn't stop anything. I get the spinning wheel icon but nothing ever happens. If you refresh the dashboard it's still active and repeated tries do nothing. Is there another way to stop the service? Even if it's cli at least I might be able to update and reboot.

[EricPerl]

I guess I could have looked at the df output...

With regards to stopping Suricata:
The widget doesn't work even if you try to stop the service BEFORE the update (which was the recommendation)?
I'm not totally surprised it doesn't work when it's blocking shutdown (it's probably deadlocked at that point).

Anyway, from the command line, you need to kill the process that's hanging reboot.
The command (given by Patrick earlier) is

Code Select Expand

kill -9 pidwhere pid is the [process] id of the hung process.

To figure out the pid, you have several options, mostly coming from the output of

Code Select Expand

ps awwux
If you observe the output of the command in reply #7, it looks like suricata was hogging the CPU. That's a hint.
Then you have several pwait processes featuring the suricata pid on their command line. pwait waits for that process to terminate...
I suspect you had that many because of several attempts to upgrade/reboot.
pwait was probably invoked by the upgrade/reboot procedure to wait for all services to terminate gracefully. Using the id on the pwait command line is probably a safe bet. Careful if the output wrapped...
When you tried to reboot, the pid in question was also featured (reply #8).

If you strongly suspect suricata, I think you will also find the id in /var/run/suricata.pid (just looking at the suricata command line)...
In that instance the command was 'kill -9 64000'