[patch] halt/reboot/shutdown cleanup

[Warner Losh]

On May 16, 2012, at 1:50 PM, Doug Barton wrote:

> On 05/14/2012 07:36, 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.
> 
> Just to be clear, I wasn't mocking you. I recently did actually mock
> someone for something that seemed so totally impossible that I felt it
> was safe to mock, and it turned out I was wrong. So what I'm trying to
> get at is what your real concerns are.

Yea.  I'm having a colorful backstory in my life, so I'm a little more touchy than normal.  Sorry if I needlessly flew off the handle.

> If you seriously hate messages saying that things are shutting down
> properly, and that's a key issue for you objecting to the change that
> Jilles is proposing, we can look at ways to mitigate that. If what
> you're really saying is, "I want to do it the old way, no matter what,"
> that's a whole different issue.

Nah, I'm just expressing concern that existing users, as well as existing programs, expect things a certain way and to change things for no better than aesthetics is unwise.  In the course of the discussion, it's clear that there's more to it than that, and some accommodation is needed...

>>>> 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.
> 
> The problem is that people see the names "halt" and "reboot" and assume
> that "simpler is better" and use them. The fact that the proper way to
> reboot a FreeBSD system is 'shutdown -r' is ... just silly.

Right, but this is the historical way things have been done, and there are many existing users who have products that depend on the difference.  So the argument for change needs to be stronger.

I think a more proper argument could be made that the times have changed and that while it would be desirable to retain the old interface, it is more desirable to file off the rough edges from the crufty old interfaces to improve the user experience for the hordes that are coming from the Linux world.

Of course, if all reboot is going to do is call shutdown -r now, then maybe it makes sense to just install a shell script called reboot and rename the current reboot to fastreboot.

>> See my other post for a way forward, sans bogusly scary names.
> 
> I've read the other messages in the thread, and I'm glad to see we're
> converging on a way forward. I don't like the names fast{halt|reboot}
> because they still sound "better" than the proper solutions to an
> unsophisticated user. My first choice would be something like unsafe,
> but I'd settle for something like old as the prefix. Then we can make
> 'reboot' do what 'shutdown -r' does, and 'halt' equivalent to 'shutdown
> -p'.

Well, a simple alias in root's .profile could do that :)  Sadly, that's not a sufficient solution for a number of reasons.

However, I think that we can get most of what is needed here by tightening up the shutdown -r path, and reinventing[*] fasthalt and fastreboot from SunOS 4.x days.  Then reboot/halt could easily be a simple shell script that invokes shutdown.  This would allow the embedded folks to replace it with fast*, while allowing the enterprise customers a more uniform experience with their linux and solaris systems.  And the tightening up would likely cause the developer community to not notice as much the difference, because the artificial delays have been removed.  Or to add to their .profile/.cshrc files something along the lines of alias reboot fastreboot.

Warner

[*] I say reinventing here because IIRC fastboot also suppressed the full fsck of filesystems when the system is coming back up.  with zfs, ufs + suj, the clean flag short-curcuit, etc that functionality is no longer all that useful.