It does an immediate shutdown, this may result in data-loss.
> If --force is specified twice, the operation is immediately executed without terminating any processes or unmounting any file systems. This may result in data loss. Note that when --force is specified twice the halt operation is executed by systemctl itself, and the system manager is not contacted. This means the command should succeed even when the system manager has crashed.
I think init still can receive signals. The only kernel ju-ju linux adds is it only delivers the signal if init has installed a handler (SIG_DFL behavior isn't triggered.)
In the old days, init would respond to a HUP by restarting... sort of a "warm boot." Pretty sure SunOS 4.1 did this, but ultrix certainly did. SVR 4 and Solaris changed the behaviour to just reading /etc/inittab.
I mean, using --force twice to get different behaviour to just one --force is a bit funky, but having a way to force an ungraceful reboot from the terminal might be useful if the system is wedged in some way and you can't do a graceful reboot. (Although in many cases you could just hold the power button on the box / use ILO / use the cloud providers admin panel to similar ends).
So the thing to remember is that in POSIX shell (and BASH, etc.) all for loops are for-each loops. If you wanted to loop over integers, you might write `for i in $(seq 10); do echo $i; done`, but that just turns into `for i in 1 2 3 4 5 6 7 8 9 10; do echo $i; done` when it runs. So this one just iterates over "s", "u", and "b" instead.
Can't tell you the exact reasons but it happens to me once in a while, usually something in the network stack hanging. Laptops usually, so I just long-press the power button to "fix" it.
Not for laptops, but, there are machines that don’t have power buttons. Or where the power buttons are somewhere in a warehouse you are not even supposed to know where it is.
A process that's stuck on an NFS operation is unkillable, even by a SIGKILL from the root user. So any shutdown/reboot procedure that has a "kill all processes" step will be unable to complete (unless it has a timeout).
It sounds like systemctl --force --force reboot will just invoke the `reboot` syscall directly and thus avoid this issue.
Yeah, that happens when a process is in D state (uninterruptible sleep). This happens for example if the process is waiting for io from a block device that has gone forever, like an nfs mount with a broken connection, but i also remember this happening in a company where somebody had the unfortunate idea of “retrofitting” (I’m using kind words here…) zfs to run on some rhel6 hosts, and it would hang very often (of course… but hey, we get snapshots without paying for a netapp).
For a regular reboot to work, all file-systems must be able to unmount cleanly.
If you for whatever reason have a file-system which have become non-responsive and is “hanging” any process which tries to interact with it, regular “systemctl reboot” and “systemctl reboot -force” may fail to actually trigger a reboot, further preventing you from fixing your issue with the non-responsive file-system.
In these cases “systemctl reboot —force —force” is useful. Especially on remote machines you cannot physically power-cycle.
I don’t remember the exact specifics beyond that, but this has happened to me and I’ve needed this at least once.
39 comments
[ 3.1 ms ] story [ 81.3 ms ] thread> If --force is specified twice, the operation is immediately executed without terminating any processes or unmounting any file systems. This may result in data loss. Note that when --force is specified twice the halt operation is executed by systemctl itself, and the system manager is not contacted. This means the command should succeed even when the system manager has crashed.
Of course, it's a measure of last resort, but there's not reason not to let root do it (i.e. expose an interface to the syscalls that already exist).
maybe even
echo sub > /proc/sysrq-trigger
echo s .. # sync echo u .. # unmount echo b .. # reboot
Just a guess though
- switch keyboard to _r_aw mode
- gracefully t_e_rminate all processes
- k_i_ll all remaining processes
- _s_ync filesystems
- _u_nmount filesystems
- re_b_oot
You need the "loop" to feed the characters one-by-one to /proc/sysrq-trigger.
Thanks for the explanation what the "sub" did (and more).
It sounds like systemctl --force --force reboot will just invoke the `reboot` syscall directly and thus avoid this issue.
For a regular reboot to work, all file-systems must be able to unmount cleanly.
If you for whatever reason have a file-system which have become non-responsive and is “hanging” any process which tries to interact with it, regular “systemctl reboot” and “systemctl reboot -force” may fail to actually trigger a reboot, further preventing you from fixing your issue with the non-responsive file-system.
In these cases “systemctl reboot —force —force” is useful. Especially on remote machines you cannot physically power-cycle.
I don’t remember the exact specifics beyond that, but this has happened to me and I’ve needed this at least once.
It has happened to me several times on debian, pc accessible by SSH, I try to reboot and it gets stuck
This is an actual thing. Systemd was a mistake.