From owner-freebsd-arch@FreeBSD.ORG Mon May 14 14:58:07 2012 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D72161065670; Mon, 14 May 2012 14:58:07 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 85A9B8FC0C; Mon, 14 May 2012 14:58:07 +0000 (UTC) Received: from 63.imp.bsdimp.com (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id q4EEqiP4042857 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Mon, 14 May 2012 08:52:44 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <3D895644-0BA5-44F7-AC8F-07323729C1AA@bsdimp.com> Date: Mon, 14 May 2012 08:52:44 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <88BE52F2-E8CC-455D-B7AF-CB1F876D48B7@bsdimp.com> References: <20120513220646.GA12826@stack.nl> <4FB0CF88.5010309@FreeBSD.org> <3D895644-0BA5-44F7-AC8F-07323729C1AA@bsdimp.com> To: Warner Losh X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Mon, 14 May 2012 08:52:45 -0600 (MDT) Cc: Doug Barton , Jilles Tjoelker , freebsd-arch@FreeBSD.org Subject: Re: [patch] halt/reboot/shutdown cleanup X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 14:58:08 -0000 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=