Shutting down quickly (And safely)

Question

I'm currently writing a research paper on the power consumption of a raspberry pi 3 and a raspberry pi zero wireless.

One question I have as far as shutdown goes (I'm trying to achieve a powered off state as quickly as possible for duty-cycling):

Can we safely call halt -f? From my understanding, it doesn't explicitly unmount the sdcard filesystems, but it does call sync first, as you have to pass the -n flag for it not to. Additionally, as the green LED stays lit, it seems the card continues to be powered until after the CPU is completely shutdown, meaning any wear-leveling operations should certainly have time to finish.

I'm aware some executables really should be called before shutdown, such as those for saving the random seed and the fake-hwclock value, but that should be it, right? Or am I missing something and we really do need to call shutdown?

Any help would be appreciated. Citations would be helpful, but are not necessary, I've been looking into this for a while and am perfectly happy doing more work if someone can just point me in the right direction.

TL;DR: Is calling halt-f regularly on an RPi safe for the SDCard?

You may find this educational https://unix.stackexchange.com/questions/8690/what-is-the-difference-between-halt-and-shutdown-commands I did test halt -f while ssh - not too friendly , but immediate ! — Jan Hus, Aug 25 '18 at 02:54
Thanks @JanHus , I did see that. One thing that concerns me is there may be a race condition between the sync command and any other process which may be not be killed before the filesystems are forcibly unmounted, and I'd like to avoid cutting the SDCard power before writes to the SDC are finished to avoid corrupted blocks. Or is that possible? Maybe I don't have to worry about a race condition, maybe it kills all other processes before sync is run? — taigrr, Aug 25 '18 at 02:58

crasic · Accepted Answer · 2018-08-25T05:18:45.280

When used the way you have it, halt uses reboot syscall.

halt When called with --force or when in runlevel 0 or 6, this tool invokes the reboot(2) system call itself and directly reboots the system. Otherwise this simply invokes the shutdown(8) tool with the appropriate arguments. Source: https://linux.die.net/man/8/halt

shutdown, is not a syscall but an application. It goes through other system utilities to gracefully shutdown by closing applications and daemons in a defined order (specific to OS)

From the pov of the SD Card Health, the reboot syscall will safely halt the kernel and machine, it will also sync the file system and all that so it will preserve, for most purposes, the systems ability to boot without corruption.

However, any application state that has not been saved or written to kernel buffers will be lost. shutdown will generally send signals to applications before killing them outright, reboot bypasses any process level gracefuleness.

IMO for a power consumption experiment, the small risk of corruption is not a big deal, for production use that is another matter. I have used it myself to conduct similar experiments to what you are proposing in a commercial setting. To be more sure, you can explicitly invoke sync before the hard halt

sync && halt -f

Kernel Details

reboot in this case is a system call implemented in kernel/reboot.c that will eventually trigger either machine_restart , machine_halt, or machine_poweroff in the arm specific architecture files reboot.c

Note: In kernel land shutdown is used to restart or switch kernels, and not the same as operating system shutdown utility. reboot is a system call that handles restart , halt and poweroff

The kernel differentiates between halt and poweroff but only slightly, the poweroff goes through any power management system. In the case of the BCM there is no ability to power off externally.

/**
 *  kernel_halt - halt the system
 *
 *  Shutdown everything and perform a clean system halt.
 */
void kernel_halt(void)
{
    kernel_shutdown_prepare(SYSTEM_HALT);
    migrate_to_reboot_cpu();
    syscore_shutdown();
    pr_emerg("System halted\n");
    kmsg_dump(KMSG_DUMP_HALT);
    machine_halt();
}
EXPORT_SYMBOL_GPL(kernel_halt);

/**
 *  kernel_power_off - power_off the system
 *
 *  Shutdown everything and perform a clean system power_off.
 */
void kernel_power_off(void)
{
    kernel_shutdown_prepare(SYSTEM_POWER_OFF);
    if (pm_power_off_prepare)
        pm_power_off_prepare();
    migrate_to_reboot_cpu();
    syscore_shutdown();
    pr_emerg("Power down\n");
    kmsg_dump(KMSG_DUMP_POWEROFF);
    machine_power_off();
}
EXPORT_SYMBOL_GPL(kernel_power_off);

(https://github.com/raspberrypi/linux/blob/rpi-4.14.y/kernel/reboot.c#L241-L268)

On the arm side this is even more straight forward, halt calls poweroff

void machine_halt(void)
{
    machine_power_off();
}

/*
 * Power-off simply requires that the secondary CPUs stop performing any
 * activity (executing tasks, handling interrupts). smp_send_stop()
 * achieves this. When the system power is turned off, it will take all CPUs
 * with it.
 */
void machine_power_off(void)
{
    local_irq_disable();
    smp_send_stop();

    if (pm_power_off)
        pm_power_off();
}

I do not believe that the bcm implementation defines any further specific pm_power_off, but that would be very low level, chip clock and power management reset, well after the kernel is done closing up shop.

For an example of how this halt looks in C, see this answer on so

#include <unistd.h>
#include <linux/reboot.h>

int main() {
    reboot(LINUX_REBOOT_MAGIC1, 
           LINUX_REBOOT_MAGIC2, 
           LINUX_REBOOT_CMD_POWER_OFF, 0);
}

which is equivalent to halt --poweroff -f

No, its a use case issue, userspace applications are prone to corruption in this manner, many applications with heavy IO load increase the chance, but for your experiment it is not too critical IMO, I have done 10-100K reset cycle experiments on a bare system using reboot -f it is not as big of a deal as people make it out to be, certainly not for an academic experiment on power consumption, where you can reimage the sd card in the worst case — crasic, Aug 25 '18 at 05:11
In any case, it is considered better to wait to accept an answer regardless, — crasic, Aug 25 '18 at 05:12
I originally accepted your answer and added a thank you for your detailed reply. But on closer inspection it seems what you're saying conflicts with what is posted in my answer, if I understand you correctly. According to the post I referenced in my answer, halt -f is now linked to systemctl halt with two force flags. Using one force is safe, two makes it skip the sync phase. Is that your understanding? Also, the paper's findings should be usable in a commercial setting, hence the care I'm putting on reducing the chance of corruption. — taigrr, Aug 25 '18 at 05:14
Apologies for the misordered comments. My phone died as I was editing one, I'm not super sure what happened. — taigrr, Aug 25 '18 at 05:16
No Problem, systemctl is just another wrapper, it will invoke userspace sync to flush any open buffers, then call the same utility. This approach is probably more thorough than what the kernel does. Kernel shuts down itself which will sync file system in most architectures, but I have not verified in rpi — crasic, Aug 25 '18 at 05:17
Okay. I was originally calling sync &&halt -f (the pi automatically powers off with just halt) and but I wasn't sure if it was possible for a userspace app to write data in between those sides of the command and thus make the sync useless, even if the chance was small. — taigrr, Aug 25 '18 at 05:20
It is small, dependent on I/O load and applications running. But on the other hand you are performing an experiment not selling a product that needs to survive a bunch of resets, it's up to you if the saved time is worth the risk and wasted time reflashing (or if this invalidates your results). I interpreted your question as damaging the SD Card hardware (it won't) — crasic, Aug 25 '18 at 05:23
Thanks, that's what I thought. The findings of the paper will be used as the foundation for a real-world IoT app in a few months, so I think I should target the level of safety that would be required for deployment. Thanks for all the help! — taigrr, Aug 25 '18 at 05:26
Most consumer IOT devices I know of usually are expected to survive a user yanking the power. The approach there is stripping the kernel and user space, and using a Read Only root FS for production. Relying on sane shutdown is a recipe for unhappy users. — crasic, Aug 25 '18 at 05:28
Yes, agreed. Fortunately I won't have "users" per say, and humans won't have physical access, and UPSes will be used. If it weren't the case I probably would have gone with read-only fs and just cutting the power instead of safely shutting down, but we need to be able to frequently update software and machine learning models, so we can't have a read-only data partition, and due to wear-leveling it doesn't make sense to have any less than all the partitions read only. — taigrr, Aug 25 '18 at 05:34

score 1 · Answer 2 · answered Aug 25 '18 at 04:22

Using halt -f is apparently a bad idea. It can corrupt data. about halt and systemd. The fastest safe way to shutdown a pi appears to be systemctl halt --force.

This extremely thorough answer was very helpful for understanding more about runlevels (or rather their obsolescence) and how different variants of shutdown, halt, and reboot commands operate under the hood. For example, it was where I learned halt -f is actually equivalent to systemctl halt --force --force which, according to the documentation, may corrupt data.

for the record as per my answer, halt -f is literally a kernel call to kill the system, systemctl halt --force --force by necessity goes through same system call. — crasic, Aug 25 '18 at 05:13

Shutting down quickly (And safely)

2 Answers2

Kernel Details

Linked