Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 23 Jun 2022 11:57:52 -0700
From:      Bryan Drewery <bryan-lists@shatow.net>
To:        freebsd-arch@freebsd.org
Subject:   Re: Updating reboot's default
Message-ID:  <1f81bf6a-4600-9966-b8fb-e62828510850@shatow.net>
In-Reply-To: <CANCZdfq0bkw4RGy=HoQhx0VHck=JQzoiONWifMY3n37Mpgz17w@mail.gmail.com>
References:  <CANCZdfq0bkw4RGy=HoQhx0VHck=JQzoiONWifMY3n37Mpgz17w@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On 6/21/2022 7:01 AM, Warner Losh wrote:
> 15 or 20 years ago, we talked about changing the default for reboot from 
> 'right now' to being safe shutdown. There were arguments made against it 
> due to tiny appliances and such.
> 
> Time has past, and this oddity has persisted. It's time to revisit that 
> decision.
> 
> I'd propose that we keep 'fastboot' and 'fasthalt' having the immediate 
> behavior. However, the 'reboot' command will switch from '-q' behavior 
> to '-r' behavior.
> 
> I'll update the man page, etc to reflect these new defaults. Most of the 
> systems I've been on in the last 10-15 years have had some flavor of 
> 'alias reboot reboot -r' in their login scripts and/or made shell 
> scripts that did this. This will match what everybody else is doing, and 
> will likely result in less astonishment rather than more, even though it 
> changes a long-standing default behavior.
> 
> Comments?
> 
> Warner
> 

<Responding to the thread>
(This isn't about reboot -q as that isn't the default nor does fast* use it)

I knew about the distinction of "reboot" and "shutdown -r" but at some 
point misread the "shutdown -o" branch in shutdown.c and misremembered 
that they were the same (added in with more Linux exposure). I only ever 
used "shutdown" when I wanted a controlled, and timed, 
interactive-user-friendly event. That was the only distinction I thought 
there was. Reading the difference in the 2 manpages still makes me think 
that's the only difference.

rc.shutdown behavior is not documented in either reboot(8) nor 
shutdown(8)."reboot" avoids rc.shutdown which can cause things like 
virtualbox to not save vm state, or not wait for processes that take a 
long time to save their data to disk (minutes) before they get SIGKILL'd 
by init after hardcoded as-little as *5* seconds and only as long as 60. 
This is where the "fast" aspect comes from - because it does not care 
about your data or give you any way to control the timing. Losing data 
has been the most astonishing thing for me.

reboot - avoids rc.shutdown
halt - avoids rc.shutdown
fastboot/fasthalt - avoids rc.shutdown
shutdown - calls rc.shutdown
poweroff - calls rc.shutdown
reboot -r - calls rc.shutdown

"reboot" suddenly using rc.shutdown is a safer change isn't it? It's 
technically a violation of historical behavior but it is one towards 
safety. I would argue it is the opposite of POLA.

The behaviors seem arbitrary and inconsistent and more a relic of 
historical decisions. We could debate semantics about these words as we 
all have subjective ideas on them, especially shaped by historical 
behavior. Consider what new fresh users, from Linux and Windows and Mac 
OS, all think. Or just what the english words mean.

None of the words mean "now" or "unsafe" vs "controlled" or "safe" to 
me. They just mean a specific event occurs. Why is "halt" a "right now" 
thing but "poweroff" is not? "shutdown" to me means what "poweroff" does 
today. "reboot" and "shutdown" are almost logically the same with 1 
trivial difference: whether the system comes back up. Why would 
"shutdown -r" make any more sense for rebooting than "reboot" from a new 
user perspective? Why should words that are practically synonyms, or in 
the same category logically speaking, be safe on one and unsafe on the 
other?

 > The fasthalt and fastboot utilities are nothing more than aliases for 
the halt and reboot utilities.

Well gee "fast" makes sense so why does the [not fast] still use the 
"fast"?! Why do these fast ones even exist?


-- 
Bryan Drewery



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1f81bf6a-4600-9966-b8fb-e62828510850>