From nobody Thu Jun 23 18:57:52 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id D27988629B9 for ; Thu, 23 Jun 2022 18:58:02 +0000 (UTC) (envelope-from bryan-lists@shatow.net) Received: from mail.xzibition.com (mail.xzibition.com [52.11.127.251]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4LTTzG0XGFz3tJ4 for ; Thu, 23 Jun 2022 18:58:01 +0000 (UTC) (envelope-from bryan-lists@shatow.net) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id EE86D209DF for ; Thu, 23 Jun 2022 11:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id ODxWnPdG-8zX for ; Thu, 23 Jun 2022 11:57:52 -0700 (PDT) Message-ID: <1f81bf6a-4600-9966-b8fb-e62828510850@shatow.net> DKIM-Filter: OpenDKIM Filter v2.10.3 mail.xzibition.com 6389A209D6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=shatow.net; s=mxc204805312015; t=1656010672; bh=DjaUtl7DBF16jfSElx3i0NMEJy8Un/QqaH+omksA3Pk=; h=Date:Subject:To:References:From:In-Reply-To; b=jFm7KLZpAChW8lK3lkUnSUVLGSxtqL8d1W7HW7aIoLX3cd6GDcK19M8l039TLOWyh qXLsAkSIumL2RUmq3Z5N1gPbivvt8r8wKt35+pf10h3tLw1COTad9isjYQcJcs2HTU 6A7huxDQrPGiZrveGFcZjg32oc6Kktbej1B0QuTc4suEMNchMAyp6E+oaXfA6KcJ9L Sjpg2w0puS/9glbS0mwdguOlrwmDUvLSv3V6Vg3Fkt6Vg2lc9znKFltBGWTow8cypc 9IBjV2c+R/jY2E8NT2KSOeJQL4VXk80DnMLkDsgCQ8MF6Fcr+KyvvKf06s5zpJdjCF chD/3/u2OH3xQ== Date: Thu, 23 Jun 2022 11:57:52 -0700 List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Subject: Re: Updating reboot's default Content-Language: en-US To: freebsd-arch@freebsd.org References: From: Bryan Drewery In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4LTTzG0XGFz3tJ4 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=shatow.net header.s=mxc204805312015 header.b=jFm7KLZp; dmarc=pass (policy=none) header.from=shatow.net; spf=pass (mx1.freebsd.org: domain of bryan-lists@shatow.net designates 52.11.127.251 as permitted sender) smtp.mailfrom=bryan-lists@shatow.net X-Spamd-Result: default: False [-4.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[shatow.net:s=mxc204805312015]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[shatow.net:+]; DMARC_POLICY_ALLOW(-0.50)[shatow.net,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-arch]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:16509, ipnet:52.10.0.0/15, country:US]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N 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 > (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