Systemd: how to shut down without actually shutting down

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
2
down vote

favorite












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?







share|improve this question






















  • A related question is superuser.com/questions/900109 .
    – JdeBP
    Mar 17 at 10:37














up vote
2
down vote

favorite












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?







share|improve this question






















  • A related question is superuser.com/questions/900109 .
    – JdeBP
    Mar 17 at 10:37












up vote
2
down vote

favorite









up vote
2
down vote

favorite











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?







share|improve this question














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?









share|improve this question













share|improve this question




share|improve this question








edited Mar 17 at 17:23

























asked Mar 17 at 0:12









Bethanie

112




112











  • A related question is superuser.com/questions/900109 .
    – JdeBP
    Mar 17 at 10:37
















  • A related question is superuser.com/questions/900109 .
    – JdeBP
    Mar 17 at 10:37















A related question is superuser.com/questions/900109 .
– JdeBP
Mar 17 at 10:37




A related question is superuser.com/questions/900109 .
– JdeBP
Mar 17 at 10:37










2 Answers
2






active

oldest

votes

















up vote
2
down vote













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





share|improve this answer




















  • See also unix.stackexchange.com/questions/195898 and unix.stackexchange.com/questions/8690 for more on this.
    – JdeBP
    Mar 17 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.
    – Bethanie
    Mar 17 at 17:18











  • If you're concerned about the filesystems, you can execute echo u >> /proc/sysrq-trigger to remount as read-only as many disks as possible.
    – dsstorefile1
    Mar 17 at 18:07

















up vote
0
down vote













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.






share|improve this answer




















  • 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.
    – Bethanie
    Mar 25 at 22:02











  • It fails this way even if /sbin/kexec-sleep only contains exit 0...
    – Bethanie
    Mar 25 at 22:21










Your Answer







StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: false,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);








 

draft saved


draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f430707%2fsystemd-how-to-shut-down-without-actually-shutting-down%23new-answer', 'question_page');

);

Post as a guest






























2 Answers
2






active

oldest

votes








2 Answers
2






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
2
down vote













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





share|improve this answer




















  • See also unix.stackexchange.com/questions/195898 and unix.stackexchange.com/questions/8690 for more on this.
    – JdeBP
    Mar 17 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.
    – Bethanie
    Mar 17 at 17:18











  • If you're concerned about the filesystems, you can execute echo u >> /proc/sysrq-trigger to remount as read-only as many disks as possible.
    – dsstorefile1
    Mar 17 at 18:07














up vote
2
down vote













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





share|improve this answer




















  • See also unix.stackexchange.com/questions/195898 and unix.stackexchange.com/questions/8690 for more on this.
    – JdeBP
    Mar 17 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.
    – Bethanie
    Mar 17 at 17:18











  • If you're concerned about the filesystems, you can execute echo u >> /proc/sysrq-trigger to remount as read-only as many disks as possible.
    – dsstorefile1
    Mar 17 at 18:07












up vote
2
down vote










up vote
2
down vote









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





share|improve this answer












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






share|improve this answer












share|improve this answer



share|improve this answer










answered Mar 17 at 0:19









dsstorefile1

1,576212




1,576212











  • See also unix.stackexchange.com/questions/195898 and unix.stackexchange.com/questions/8690 for more on this.
    – JdeBP
    Mar 17 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.
    – Bethanie
    Mar 17 at 17:18











  • If you're concerned about the filesystems, you can execute echo u >> /proc/sysrq-trigger to remount as read-only as many disks as possible.
    – dsstorefile1
    Mar 17 at 18:07
















  • See also unix.stackexchange.com/questions/195898 and unix.stackexchange.com/questions/8690 for more on this.
    – JdeBP
    Mar 17 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.
    – Bethanie
    Mar 17 at 17:18











  • If you're concerned about the filesystems, you can execute echo u >> /proc/sysrq-trigger to remount as read-only as many disks as possible.
    – dsstorefile1
    Mar 17 at 18:07















See also unix.stackexchange.com/questions/195898 and unix.stackexchange.com/questions/8690 for more on this.
– JdeBP
Mar 17 at 10:39




See also unix.stackexchange.com/questions/195898 and unix.stackexchange.com/questions/8690 for more on this.
– JdeBP
Mar 17 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.
– Bethanie
Mar 17 at 17:18





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.
– Bethanie
Mar 17 at 17:18













If you're concerned about the filesystems, you can execute echo u >> /proc/sysrq-trigger to remount as read-only as many disks as possible.
– dsstorefile1
Mar 17 at 18:07




If you're concerned about the filesystems, you can execute echo u >> /proc/sysrq-trigger to remount as read-only as many disks as possible.
– dsstorefile1
Mar 17 at 18:07












up vote
0
down vote













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.






share|improve this answer




















  • 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.
    – Bethanie
    Mar 25 at 22:02











  • It fails this way even if /sbin/kexec-sleep only contains exit 0...
    – Bethanie
    Mar 25 at 22:21














up vote
0
down vote













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.






share|improve this answer




















  • 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.
    – Bethanie
    Mar 25 at 22:02











  • It fails this way even if /sbin/kexec-sleep only contains exit 0...
    – Bethanie
    Mar 25 at 22:21












up vote
0
down vote










up vote
0
down vote









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.






share|improve this answer












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.







share|improve this answer












share|improve this answer



share|improve this answer










answered Mar 17 at 23:36









mulad

962




962











  • 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.
    – Bethanie
    Mar 25 at 22:02











  • It fails this way even if /sbin/kexec-sleep only contains exit 0...
    – Bethanie
    Mar 25 at 22:21
















  • 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.
    – Bethanie
    Mar 25 at 22:02











  • It fails this way even if /sbin/kexec-sleep only contains exit 0...
    – Bethanie
    Mar 25 at 22:21















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.
– Bethanie
Mar 25 at 22:02





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.
– Bethanie
Mar 25 at 22:02













It fails this way even if /sbin/kexec-sleep only contains exit 0...
– Bethanie
Mar 25 at 22:21




It fails this way even if /sbin/kexec-sleep only contains exit 0...
– Bethanie
Mar 25 at 22:21












 

draft saved


draft discarded


























 


draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f430707%2fsystemd-how-to-shut-down-without-actually-shutting-down%23new-answer', 'question_page');

);

Post as a guest













































































Popular posts from this blog

Peggy Mitchell

The Forum (Inglewood, California)

Palaiologos