Systemctl –Force –Force Reboot | Hacker News Reader

Systemctl –Force –Force Reboot

26 pointsmkesper39 comments

Yesterday I learned that is a thing:

    systemctl --force --force reboot

View on HN

If you don't want to rely on any specific init system, and not even any external commands (with most shells):

  echo b > /proc/sysrq-trigger

More options (and when you have a keyboard): https://en.wikipedia.org/wiki/Magic_SysRq_key

Official docs: https://www.kernel.org/doc/html/latest/admin-guide/sysrq.htm...

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

Some tools do the same with --verbose, so it's not without precedent.

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

This is the same as `reboot -f` without systemd.

Pretty sure “reboot” is aliased to a systemctl command but I’m not 100% on this.

On systems without systemd, it (obviously) isn't.

I've never had issues with a plain old "reboot" on systemd machines... just curious, why you would need to force it?

Main reason I can think of is you are a kernel developer and you have broken your own kernel in such a way that the regular reboot hangs.

Sometimes, we break our tools with our tools.

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.

Then you hopefully have OOB management instead, or?

Hopefully, but most embedded thingies don't have the luxury of a smaller computer to tend to the bigger one.

I've encountered issue when NFS mount can block regular system reboot when the network connection is broken.

Interesting. I would have figured systemd would have coded around that. (Not that I've tried)

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

> just curious, why you would need to force it?

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.

Sometimes systemd does not reboot the pc because of some random service not closing

It has happened to me several times on debian, pc accessible by SSH, I try to reboot and it gets stuck

for i in s u b; do echo "$i" > /proc/sysrq-trigger; done

maybe even

echo sub > /proc/sysrq-trigger

Please explain the loop version.

That's just a sequence of commands

echo s .. # sync echo u .. # unmount echo b .. # reboot

Just a guess though

It's not really a loop, it's the second half of the REISUB magic sequence (https://en.wikipedia.org/wiki/Reisub?skin=timeless#Uses):

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

Here I thought "for" was a loop.

Thanks for the explanation what the "sub" did (and more).

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.

Bruh. The mansplaining over the word "loop" is insane.

I think you want to wait a bit after the s.

How about pressing Ctrl+Alt+Delete 7 times in quick succession?

This is an actual thing. Systemd was a mistake.

AFAIK, C-A-D doesn't work over ssh.

What does it do?

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.

so it's like `kill -HUP 1` then?

Wouldn’t HUP require PID 1 to be able to process signals?

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

I don't know what systemd does with HUP, but traditional inits respond to HUP by reparsing their configs, not rebooting.

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.

ibmuserspacectl -force -force shutdown

Reply on news.ycombinator.com