Re: Should reboot(8) be modified so that it can become the recommended way to reboot a system?

On Sun, Feb 9, 2025 at 10:00 AM Poul-Henning Kamp <phk@phk.freebsd.dk>
wrote:

> --------
> Daniel Tameling writes:
>
> > Part of the problem is that reboot indeed reboots the system.
>
> I understand what you are saying, but there's no way it can be a
> "problem" that a command called "reboot" reboots the system :-)
>
> If we dont want to make this a flag-day and break a lot of scripts,
> and other automation, the only option, is to make reboot(8) and
> halt(8) print a message and sleep long enough that people can
> change their mind.
>
> My suggestion would be:
>
> If reboot(8) or halt(8) is invoked with any other argument than
> '-p', they behave as documented today.
>
> If they are invoked without arguments, or with only the '-p' argument,
> it goes something like:
>
>         # reboot
>
>         If you want things to be stop nicely:
>
>             Press CTRL-C now, and use the shutdown(8) command instead.
>
>         3
>         2
>         1
>         rebooting
>
> That clearly communicates what the concern is, gives people a sensible
> chance to change their mind, and does not break any existing scripts.


I have a contrary view. I think we should make some changes. But we can't
just exec shutdown, the args / history / evolution of reboot is too
complicated for that.

tl;dr: (1) reboot -r is the hardest thing. It's actually a FreeBSD specific
thing that people care about and is different than shutdown -r, so we can't
make reboot a link to shutdown. The rest is very straight-forward with only
one real behavior change.

fasthalt and fastboot should all remain unchanged: they reboot w/o killing
system processes. This is in line with historic practice, but that history
is from the 90s so nice to have, but not super relevant. This also matches
what Linux does. It also preserves a fast way to start over. Add -f for
linux compatibility too. -q remains unchanged, since it would force -f.
Though for linux compat we may want to consider not doing that last detail:
reboot -q -> shutdown -r -q in linux (the latter has the same meaning in
FreeBSD: quietly shutdown rather than quickly.) But, alas, '-q' doesn't
klil all the processes.

w/o args we change from calling reboot(2) directly to execing shutdown.
There the change is intentional: /etc/rc.shutdown is run where it wasn't
before. People that have scripts that depend on this detail are kinda hozed
anyway: killing the demons unexpectedly will leave things in a weird state
and this pushes that behavior to intentionally using -f rather than being
just a historical accident.  I'd be happy with a 3 second countdown like
the above but with the message flipped. If people really really need it,
env var to enable old behavior (and even then it would print the new
message phk recommends, etc).  reboot/halt -c, -p -> same behavior, and
those flags are passed to shutdown. This would also fix the mismatch
between halt -p and poweroff.

-e, -d, -D, -k, -l, -o -> no change: reboot handles managing nextboot.
shutdown not invoked.

-n -> passed to shutdown

-N  should just invoke shutdown and be otherwise swallowed up.

-r -> becomes a new reroot program (maybe a symlink to reboot, I've not
looked at how much code is shared) and reboot -r prints a warning about it
moving there. It is an outlier in the reboot program, though there's some
good logic for why it landed there. Right now, it just signals init to
reroot, so that causes rc.shutdown to run.

In the early 2000s, I thought we needed things like we had/have them. Since
then, I've shot my foot more times than not and $WORK has 'alias reboot
shutdown -r' in our .cshrc. That works great, until I want to do nextboot
things, so I'm not recommending it as a way forward. Once or twice I've
really wanted the don't run /etc/rc.shutdown behavior, the other 10k times
I've rebooted a system I've either not cared about skipping it or thought
running it was a good thing.

In summation, there's the following ways to reboot (not reroot):

(1) -q just call reboot, don't kill anything
(2) kill everything with SIGTERM to allow those programs that catch a
signal to do so and terminate more or less gracefully (delays, plus waiting
for paging to stop, etc)
(3) have shutdown do it (so -o flag). This is shutdown calling (2) after
the waiting period, but is otherwise identical to (2).
(4) Kill init and have it sort the mess. The first thing init does is run
/etc/rc.shutdown and then kills straggler processes.

It's all a confusing mess today, though people have learned it well. People
are asking that some things now cause (4) to happen rather than (2). I
think I've enumerated them above, but see my initial "too complicated"
comment.

Warner