[patch] halt/reboot/shutdown cleanup

Warner Losh imp at bsdimp.com
Mon May 14 14:58:08 UTC 2012


On May 14, 2012, at 8:36 AM, Warner Losh wrote:

> 
> On May 14, 2012, at 3:25 AM, Doug Barton wrote:
> 
>> On 5/13/2012 3:42 PM, Warner Losh wrote:
>>> 
>>> 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.
>>> 
>>> I hate these messages, which is why I always use halt or reboot to
>>> avoid them. 
>> 
>> You hate messages? Seriously?
> 
> 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.
> 
>>> I find the additional delays from doing a shutdown -r to
>>> also be annoying, which is why I never use them.
>> 
>> 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.
> 
> halt and reboot are low level interfaces.  shutdown is the higher level interface that people should use.
> 
>>>> 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).
>>>> 
>>>> 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.
>>>> 
>>>> 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.
>>> 
>>> Generally, I think this is a really bad idea, just like the last time
>>> it was proposed.
>> 
>> 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.
>> 
>> 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.
> 
> 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


More information about the freebsd-arch mailing list