What you should never do is cut the power to your PC or hard reset using the button on the computer’s case, as that may cause filesystem corruption. But any other normal means of shutting down is safe, including the poweroff command (which is just a symlink to systemctl) or using the GUI button (which is a bit gentler on some DE’s as it logs you out of your GUI session and then runs the systemctl command).
Truth be told, poweroff (but also XFCEs shutdown button which behaves exactly like poweroff) seems a bit brutal. I sometimes have VMs started and plenty of heavy and not so heavy apps running. Poweroff just kills everything in 1 to 2s. Sometimes video artifacts show on screen for a second or so. I have asked myself this question, if it’s actually safe, as in if there’s not some zeroes and ones hanging somewhere in some pipe somewhere that never make it to SSD.
In what way? The poweroff or shutdown commands won’t cause any filesystem corruption, if that is what you’re afraid of. It will send the terminate signal to all running processes or kill them if they do not obey. It will also close all open file streams, and unmount all filesystems, and when it’s done, it will power off the computer.
Whether an application saves its state to the drive is dependent on the application. Some will, some won’t, so if you have any unsaved work, it may not get written and thus be lost. That said, your filesystem will be safely unmounted and there will be no corruption to anything written on the drive.
There are no poweroff commands that will cause filesystem corruption. The only way to try and have that happen is to yank the power cable (and even then, journaling filesystems are reasonably resilient).
OP still hasn’t defined what “safe shutdown” is, or why they think it’s not happening, and I’d really like to hear about that.
Same as what Kresimir said - system won’t corrupt. (running shutdown in the terminal is my standard way)
But it doesn’t seem like applications get a “peaceful” close signal. With firefox, if there were tabs open, they are restored on next boot, which certainly means firefox wasn’t given the usual “close” signal. Instead, some form of “kill” or “terminate” signal was passed.
Yeah, I rather like that. I guess it’s a reminiscence from my Windows days that will be with me forever. I hated how windows was making itself busy and letting me know when it was safe to shutdown. So I like how nothing can escape the almighty shutdown, and all that killing happens instantly I think I’ve recently read somewhere you’re supposed to close all your applications before shutdown. Some Linux tut i can’t remember where. (I was like: “aint nobody got time for that”)
There is no need to do so, but as I’ve said above, different applications may handle interrupts differently. Some will save their state to the drive and gracefully exit when they receive the terminate signal (SIGTERM), some won’t. And some will outright disobey the terminate signal and will have to be killed (with SIGKILL, which does not give them any chance to save their state).
So, it depends on what your desired outcome is.
On KDE Plasma, there is a also “save session” option that makes the window manager remember all running applications before terminating them so that they can be launched on the next startup (trying to restore their state, if possible). It will also run any scripts you may have in ~/.config/plasma-workspace/shutdown/. This won’t happen if you shut down with the shutdown or poweroff commands.
If you’re interested in knowing how to shut down your computer from the terminal emulator on KDE Plasma in a way that is equivalent to using the GUI, read this post:
Disableusermode-helper, to ensure that no user code will be started anymore. (There can still be existing processes at this stage.)
Call device_shutdown to release or power down all devices on the system. A lot of drivers hook into this stage.
Note that any filesystems that are still mounted at this point are effectively forcibly unmounted. The caller of the system call takes responsibility for any clean unmounting.
In a multi-CPU machine, the code could be running on any CPU, whichever invoked the system call. migrate_to_reboot_cpu takes care to switch to one particular CPU and prevent the scheduler from dispatching code on other CPUs. After this point, only a single CPU is running.
Thanks, but I like the speed. I want everything to dissolve into nothing in a blink of an eye. Don’t care at all to restore my sessions. Heck my sessions get so chaotic, sometimes after I finish a complex project I restart just to get everything back to zero. Sometimes this sends a murder message to the Windows VM, oh well, I can’t wait for windows to do its “graceful” get back into your box routine