# How to instantly reboot FreeBSD system



## vermaden (Feb 15, 2018)

Hi,

on Linux I can use `reboot -f` command that would just send the ACPI to reset the system, just like You would press 'reset' button on the computer case.

I have tried to find similar command on FreeBSD but I failed, the only 'alternative' is to `reboot -q -n -l` but that still leave system hanged not rebooted.

Any hints on how to 'execute' such reboot on FreeBSD?

Thanks.


----------



## PacketMan (Feb 15, 2018)

Check out shutdown(8) .

`shutdown -r now` does an (near) instant reload.  Only reason I say near instant, is because the shutdown process takes a wee bit of time.


----------



## SirDice (Feb 15, 2018)

Maybe add -N too? I'd consider -n and -N to be quite dangerous but a combination of both is probably more like somebody pushing the reset button (which would instantly reset the machine).


```
-N      The file system cache is not flushed during the initial process
             clean-up, however the kernel level reboot(2) is still processed
             with a sync.  This option can be useful for performing a
             "best-effort" reboot when devices might be unavailable.  This can
             happen when devices have been disconnected, such as with
             iscsi(4).
```

Note that on Linux a `reboot -f` still processes reboot(2). So it's not exactly like pressing the reset button. The actual, physical, reset button resets the CPU directly, there's no ACPI involved. It can't be masked or otherwise be prevented either.

https://en.wikipedia.org/wiki/Hardware_reset


----------



## vermaden (Feb 16, 2018)

PacketMan said:


> Check out shutdown(8) .
> 
> `shutdown -r now` does an (near) instant reload.  Only reason I say near instant, is because the shutdown process takes a wee bit of time.


Quite the opposite, `shutdown -r now` does gracefully shutdown notifying `init(8)` and eventually can be started to run `reboot(8)` directly wih `-n` option, which is not what I need.

I need a comand for instant reboot, without system waiting for drives, hanging on problems, etc.


----------



## vermaden (Feb 16, 2018)

SirDice said:


> Note that on Linux a `reboot -f` still processes reboot(2). So it's not exactly like pressing the reset button.


But works.

... and `-N` option is 'stronger' then `-n` ... and still does not work (system is leaved hanged sometimes).


----------



## SirDice (Feb 16, 2018)

No IPMI? Through IPMI it's easy to press the 'physical' reset button.


----------



## PacketMan (Feb 16, 2018)

vermaden said:


> I need a comand for instant reboot, without system waiting for drives, hanging on problems, etc.



Sorry but I am a strong proponent of always trying to do a safe and clean shutdown when and where possible.  I say go buy a LAN connected power bar with remote controllable power.  Login to power bar and execute command "_power cycle_".


----------



## vermaden (Feb 16, 2018)

PacketMan said:


> Sorry but I am a strong proponent of always trying to do a safe and clean shutdown when and where possible.


Me to, but sometimes its just needed, its difference between 'dirty' reboot or going onsite by yourself with 2 hour car journey


----------



## ralphbsz (Feb 16, 2018)

Many server-grade machines have a management infrastructure, which allows low-level operations, such as power up, power down, and reset.  That management thing is often connected via an Ethernet port, and reachable.  This would be the perfect way for a really fast reboot function.  It is however hardware specific.


----------



## vermaden (Feb 16, 2018)

ralphbsz said:


> Many server-grade machines have a management infrastructure, which allows low-level operations, such as power up, power down, and reset.  That management thing is often connected via an Ethernet port, and reachable.  This would be the perfect way for a really fast reboot function.  It is however hardware specific.


Yep, but Raspberry Pi does not, and while Linux provides `reboot -f` I see no point that FreeBSD would not ...


----------



## ralphbsz (Feb 16, 2018)

Actually, if I were to implement an operating system, I would not provide that.  People should not be rebooting without a software shutdown first.  It is bad enough that we can not prevent all hardware crashes and power outages; with power outages, we can at least fight them in both hardware (UPSes) and software (keep the amount of critical data that is dirty in memory to an absolute minimum, and try to flush out as much as possible when a power fail signal is detected on the remaining energy).  We should not give end users more tools that have grave danger of shooting themselves in the foot.  If we absolutely need to provide such tools, they need to be designed in such a way that it is 1000% clear to the user that they are operating a "foot-shaped gun".

Old saying: The correct way to manage a system is to hire a man and a dog.  The man is there to feed the dog.  The dog is there to bite the man if he tries to touch the computer.


----------



## hukadan (Feb 16, 2018)

ralphbsz said:


> Actually, if I were to implement an operating system, I would not provide that. People should not be rebooting without a software shutdown first.


I would not choose an operating system that decides for me what I should or should not do.


----------



## ralphbsz (Feb 16, 2018)

Excellent, then we can be friends!  If you think that cutting power or restarting the CPU is a good use of an operating system and of the computer it runs on, then we're both better off if you wouldn't use the system that I would want to build.

This is very similar to a car.  Today it is perfectly possible for the user of a car to accelerate to high speed, and then point the steering wheel at a concrete wall, causing impact.  As the implementor of a car, there has traditionally been little I could do to prevent that use.  Actually, modern cars with self-driving and safety assist features are trying to prevent that, both by warning the user, and by overriding their decisions (like automatically applying brakes).  But it needs to be made clear to the user that deliberately slamming into a wall is not a good use of the car, and will have negative consequences.

Now, this does not imply that we can be sloppy when designing cars: they still need to be as safe against impact as reasonable possible (within the constraint that everything about design and engineering is a compromise with other goals).  Because even though we do not wish people to drive into concrete walls (or crash their CPUs), it will happen occasionally, and we need to minimize the bad consequences.  And in rare and special circumstances, we need to allow cars to deliberately crash into walls, for example when being tested by the federal department of transportation to determine whether they are crash-worthy.  Similarly, it has to be possible to inject faults (such as a CPU reset), for example during software QA testing, and customer's acceptance testing.  But we need to make it clear to users that using a hard CPU reset has to remain the rare exception, only suitable for special scenarios such as fault injection during QA testing, and that the correct way to get the machine to reboot is to do a clean shutdown.


----------



## vermaden (Feb 16, 2018)

Bug submitted: PR 225964


----------



## Eric A. Borisch (Feb 23, 2018)

Use `sysctl debug.kdb.panic=1` to trigger a panic when you want the system to go down hard. (NOTE: DON'T DO THIS UNLESS YOU REALLY, REALLY MEAN IT.) So long as sysctl kern.sync_on_panic=0 is set (the default) this should be do what you are asking for.

Alternatively, you can apparently bind a key combination to trigger a panic: Thread manual-kernel-panic.10024/#post-60474


----------



## vermaden (Feb 25, 2018)

This is EXACLY what I was looking for, thank You


----------

