poweroff complains that it can't connect to systemd via DBus (of course, it's not alive). I did sync followed by kill $$, thinking that pid 1 dying would cue the kernel to poweroff, but that caused a kernel panic. I then held the power button to force the poweroff.

What's the most proper way to power-off in this scenario?

  • There's an unstated implicit premise of the question that the systemd toolset is installed. When "there's no systemd" actually means that no systemd toolset is installed, which is how the title can also be read, answers are rather different; and that's probably worth a separate question in its own right.
    – JdeBP
    Dec 11, 2018 at 19:24
  • @JdeBP You're right that, reading only the title and ignoring the init=/bin/bash hint/implication, it's ambiguous if systemd is installed or not. I had meant that there's no systemd running. In any case, having no running systemd, I thought the systemd toolset would be useless and that answers would use other means like those about sysrq.
    – JoL
    Dec 12, 2018 at 16:16

5 Answers 5


I will simply execute below two commands:

echo s > /proc/sysrq-trigger    <= For sync
echo o > /proc/sysrq-trigger    <= For shutdown the system

Assuming magic key is enabled in kernel

  • Correct answer, imho. Thanks! Sep 28, 2022 at 11:23

Unmount the filesystems that you had mounted. The root filesystem is a special case; for this you can use mount / -o remount,ro. On Linux, umount / also happens to work, because it is effectively converted to the former command.

That said, you don't need to worry about unmounting too much, unless

  1. You have mounted an old filesystem like FAT - as used by the EFI system partition - or ext2, which does not implement journalling or equivalent. With a modern filesystem, sync is supposed to be enough, and the filesystem will repair itself very quickly on the next boot.
  2. You might have left a running process that writes to the filesystem, and you had intended to shut it down cleanly. In that case it's useful to attempt to umount the filesystems, because umount would fail and show a busy error to remind you about the remaining writer.

The above is the important part. After that, you can also conveniently power off the hardware using poweroff -f. Or reboot with reboot -f.

There is a systemd-specific equivalent of poweroff -f: systemctl poweroff -f -f. However poweroff -f does the same thing, and systemd supports this command even if it has been built without SysV compatibility.

Technically, I remember my USB hard drive was documented as requiring Windows "safe remove" or equivalent. But this requirement is not powerfail safe, and Linux does not do this during a normal shutdown anyway. It's better interpreted as meaning that you shouldn't jog the hard drive while it is spinning - including by trying to unplug it. A full power off should stop the drive spinning. You can probably hear, feel, or see if it does not stop :-).

  • Just so you know, I'm not forgetting to accept. It's just that I've seen the advice to wait some time before accepting an answer to let others (maybe in different timezones) see the question and have the chance to provide their own answers.
    – JoL
    Dec 11, 2018 at 0:42
  • sync() suffices for ext2. It will complain about being dirty but won't have actually been corrupted except for the summary information. I generally consider init=/bin/bash or any local equivalent to be an emergency situation.
    – Joshua
    Dec 11, 2018 at 16:42
  • @Joshua ext2 fsck is amazing. But fsck performance on large filesystems is much worse than journal replay. In an emergency situation, you don't want to be delayed because of an unclean unmount.
    – sourcejedi
    Dec 11, 2018 at 16:46
  • You know about fsck.mode=skip right?
    – Joshua
    Dec 11, 2018 at 16:48
  • 3
    @Joshua which is relevant why? If you do an unclean unmount, you will eventually need to repair the FS. Don't use fsck.mode=skip to boot normally after an unclean unmount!
    – sourcejedi
    Dec 11, 2018 at 16:50

Effectively, tou want to call reboot(2) syscall.

Two ways you can do this:

  1. Run reboot -f or poweroff -f, this should call reboot(2) directly.

  2. If you're on the real Linux virtual terminal (not the GUI terminal emulator), by pressing Ctrl+Alt+Delete.

Note that the keyboard shortcut can be disabled by some user space program (usually init), when disabled the shortcut will send a signal to init instead.

All of the above commands should be done after umount-ing all disks or remounting as read only, and running sync, otherwise you may lose unwritten data. If your shell is the only process running, sync may be enough.


Ok, so it just occurred to me that I had the option to exec init. From there, I would probably be able to later poweroff. I wonder if there are better alternatives, though.

  • @G-Man won't it start the normal boot process and give you your normal shell eventually?
    – muru
    Dec 11, 2018 at 2:21
  • 2
    @muru You could do exec init 0. That won't work with all init systems, but the same ones will go through a shutdown sequence. Dec 11, 2018 at 14:36
  • 1
    I think this is a really good answer for other reasons; particularly because most cases powering off isn't desired so much as rebooting and this avoids the reboot once having fixed the damage.
    – Joshua
    Dec 11, 2018 at 16:44
  • 1
    @Joshua That's convenient, but if you want to be safest, it is often a good idea to check the full boot process works :-).
    – sourcejedi
    Dec 11, 2018 at 17:17

You could use the Magic SysRq keys (https://en.wikipedia.org/wiki/Magic_SysRq_key) to power off your computer.

To shut down properly, you can use the following (quote form Wikipedia):

A common use of the magic SysRq key is to perform a safe reboot of a Linux computer which has otherwise locked up (abbr. REISUB). This can prevent a fsck being required on reboot and gives some programs a chance to save emergency backups of unsaved work.[5]  The QWERTY (or AZERTY) mnemonics: "Raising Elephants Is So Utterly Boring", "Reboot Even If System Utterly Broken" or simply the word "BUSIER" read backwards, are often used to remember the following SysRq-keys sequence:

  • unRaw (take control of keyboard back from X),
  • tErminate (send SIGTERM to all processes, allowing them to terminate gracefully),
  • kIll (send SIGKILL to all processes, forcing them to terminate immediately),
  • Sync (flush data to disk),
  • Unmount (remount all filesystems read-only),
  • reBoot.

But substituting the last B with O (for azerty/qwerty) for "power Off"


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .