1

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 unix.stackexchange.com/questions/8690/… I did test halt -f while ssh - not too friendly , but immediate ! – Jan Hus Aug 25 '18 at 2: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 2:58
1

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 5:11
  • In any case, it is considered better to wait to accept an answer regardless, – crasic Aug 25 '18 at 5: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 5: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 5: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 5:17
1

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 5:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.