Date: Mon, 14 May 2012 08:52:44 -0600 From: Warner Losh <imp@bsdimp.com> To: Warner Losh <imp@bsdimp.com> Cc: Doug Barton <dougb@FreeBSD.org>, Jilles Tjoelker <jilles@stack.nl>, freebsd-arch@FreeBSD.org Subject: Re: [patch] halt/reboot/shutdown cleanup Message-ID: <88BE52F2-E8CC-455D-B7AF-CB1F876D48B7@bsdimp.com> In-Reply-To: <3D895644-0BA5-44F7-AC8F-07323729C1AA@bsdimp.com> References: <20120513220646.GA12826@stack.nl> <CA766F13-E02E-4815-9AEE-984BC14F2CB9@bsdimp.com> <4FB0CF88.5010309@FreeBSD.org> <3D895644-0BA5-44F7-AC8F-07323729C1AA@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On May 14, 2012, at 8:36 AM, Warner Losh wrote: >=20 > On May 14, 2012, at 3:25 AM, Doug Barton wrote: >=20 >> On 5/13/2012 3:42 PM, Warner Losh wrote: >>>=20 >>> On May 13, 2012, at 4:06 PM, Jilles Tjoelker wrote: >>>> Also, the normal forms of halt and reboot will now call shutdown >>>> so users get a clear message of the event. >>>=20 >>> I hate these messages, which is why I always use halt or reboot to >>> avoid them.=20 >>=20 >> You hate messages? Seriously? >=20 > Seriously. And I'd appreciate it if you didn't mock me on this. It = is rude and insulting and not constructive to a dialog. >=20 >>> I find the additional delays from doing a shutdown -r to >>> also be annoying, which is why I never use them. >>=20 >> If things are working as they should be, running rc.shutdown won't = cause >> any delays at all vs. the brute force method used by 'shutdown'. The >> only time you'll see a delay is if something that's being killed >> actually needs it to cleanly shut down. >=20 > halt and reboot are low level interfaces. shutdown is the higher = level interface that people should use. >=20 >>>> Halt and reboot still support the -q option to invoke reboot(2) >>>> without anything else. The -d and -n options now require -q >>>> (because init is signaled if -q is not used, and init will not do >>>> dump or nosync). >>>>=20 >>>> The -l option of halt and reboot now not only suppresses logging, >>>> but also user notification. It does this by signaling init directly >>>> and not going through shutdown. >>>>=20 >>>> The -o option of shutdown goes away because there does not seem >>>> any point in executing halt or reboot if they are going to send the >>>> same signal to init anyway. >>>=20 >>> Generally, I think this is a really bad idea, just like the last = time >>> it was proposed. >>=20 >> This topic comes up very often as users are confused by the fact that = we >> have 2 different methods for shutdown/reboot, and the ones that seem = the >> most obvious (halt and reboot) are the most pathological. >>=20 >> IMO we should maintain the old behavior as binaries with scary names >> that the anachronists can use in local aliases, and we should modify >> halt and reboot in a manner similar to what Jilles is suggesting. >=20 > See my other post for a way forward, sans bogusly scary names. This may also be a cultural divide between the embedded world, where = halt means halt right now and reboot where reboot means reboot right now = and the server world where users need to be told of things and a more = generic infrastructure needs to be in place. In embedded, when you = decide to reboot, you know everybody else has cleaned up and you want to = give the best experience to the user by doing it as fast as possible. = In the server space, people that are logged in need to be told, there's = a richer framework that needs to run, etc and time to get back to = passing WiFi packets isn't as important. The distaste for extra, useless messages, I'll admit, is a personality = quirk that I share with many people. Warner=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?88BE52F2-E8CC-455D-B7AF-CB1F876D48B7>