2

I'm setting up an embedded device running Debian Jessie to shut down when a UPS experiences a power failure. Unfortunately, the device's bootloader restarts the OS whenever it quits, so shutdown/halt commands are equivalent to restart.

My main concern is protecting the data on the attached hard disks. I think my best option is to kill as many tasks as possible and then wait for the power to cut. systemctl isolate emergency.target seems close to what I want, except it leaves the disks mounted. Is there a way to basically get Systemd to final.target without an actual shutdown/halt command?

Improve this question
1

2 Answers 2

Reset to default
2

systemctl halt might do the trick. From the manual:

halt Shut down and halt the system. This is mostly equivalent to systemctl start halt.target --job-mode=replace-irreversibly --no-block, but also prints a wall message to all users. This command is asynchronous; it will return after the halt operation is enqueued, without waiting for it to complete. Note that this operation will simply halt the OS kernel after shutting down, leaving the hardware powered on. Use systemctl poweroff for powering off the system (see below).
Improve this answer
3
  • See also unix.stackexchange.com/questions/195898 and unix.stackexchange.com/questions/8690 for more on this. Commented Mar 17, 2018 at 10:39
  • Alas, no joy. As JdeBP's wonderfully in depth answer to the first question they links above says, systemctl halt and shutdown -H now are equivalent in systemd. All these commands do halt the OS kernel, but that's when the bootloader starts the system again! I need a way to shut everything else down but leave a minimal kernel running. Commented Mar 17, 2018 at 17:18
  • This is the right answer for the general question of how to halt a machine or VM running systemd. In OP's case, they have a watchdog-like system that impedes this, but I thought it would be good to mention that it is correct for the general case. (Which is what I came here for.) Commented Sep 26, 2023 at 13:31
1

Assuming this isn't just a problem with some sort of watchdog device, you can try hijacking the kexec target for systemd. That's ordinarily used for loading a kdump kernel to dump memory, but you can really set up that target to do anything.

I created a systemd unit called kexec-sleep and put it into /etc/systemd/system/kexec-sleep.service (I'm not sure if these Requires/After/Before lines are quite right, but they worked for me in a virtual machine):

[Unit] Description=Sleep forever at kexec DefaultDependencies=no Requires=umount.target After=umount.target Before=final.target [Service] Type=oneshot ExecStart=/sbin/kexec-sleep KillMode=none [Install] WantedBy=kexec.target

That will call /sbin/kexec-sleep, which is just a shell script (shown below). It attempts to remount the root filesystem read-only, so it should stay in a clean state until the device powers down. I have some sleeps in there that are probably longer than what you need, plus a prompt at the end that will let you reboot without needing to pull the power cord.

#!/bin/sh stty sane < /dev/console # enable automatic CRLF output on console exec < /dev/console > /dev/console 2>&1 # redirect stdio to/from console echo "Sleeping several seconds for processes to terminate..." sleep 10 # kill some expected processes killall dhclient # sleep again... sleep 5 echo "Processes still running:" /bin/ps --ppid 2 -p 2 --deselect # list non-kernel processes echo "Attempting to remount root filesystem read-only..." sync; sync; sync mount -o remount,ro / grep /dev/sda /proc/mounts while true; do echo "System paused. Type 'reboot' to reboot" read -p '> ' entry if [ "$entry" = "reboot" ]; then /sbin/reboot -f fi done

After creating those files, run chmod +x /sbin/kexec-sleep and systemctl enable kexec-sleep.

To trigger this instead of a normal shutdown, run systemctl kexec.

Improve this answer
2
  • This is awesome, and seems really close to working. When I run systemctl kexec, it culminates with 3 lines from systemd-shutdown[1]: Rebooting with kexec. / kexec failed with error code 1. / Rebooting. -- I don't see the expected echo outputs, so I'm not sure where the failure is. Commented Mar 25, 2018 at 22:02
  • It fails this way even if /sbin/kexec-sleep only contains exit 0... Commented Mar 25, 2018 at 22:21

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.