[arch-general] [PATCH 21/48] Both rc.single and rc.shutdown use the same code to kill everything.

[Kurt J. Bosch]

2010-09-01 22:52, Dave Reisner:
> On Wed, Sep 01, 2010 at 07:30:45PM +0200, Kurt J. Bosch wrote:
>> 2010-09-01 13:03, Dave Reisner:
>>>
>>> The _current_ behavior doesn't define an order unless its in DAEMONS.
>>> I've reverted _your_ behavior, which I don't feel has proper
>>> justification.
>>>
>> I referred to extras/initscripts which indeed does. Please read the
>> code: http://projects.archlinux.org/initscripts.git/tree/rc.shutdown?id=2010.07-1
>>
>
> Indeed, I was mistaken. However, I still stand by the idea that trying
> to parse the output of /bin/ls is flawed from the ground up. ls is made
> for human parsing, not programatical parsing.
>
>>> Suppose I start daemons foo, bar and baz (in that order) after Arch
>>> boots. Why then, should the shutdown order of these daemons change
>>> merely because I had to restart bar, which is independent of foo and
>>> baz?
>>>
>> Because you know which is the right order and rc.shutdown just rolls
>> back what you did. ^^
>>
>>
>
> No, rc.shutdown does _not_ know the right order. The current behavior is
> broken. Example:
>
> 1) start network
> 2) start rpcbind
> 3) start nfs-common
> 4) restart network
>
> network now shuts down first, rendering the OS unable to cleanly close
> any outstanding nfs shares. This commonly results in a long hang at
> shutdown and the possibility of truncated files.
>
That's exactly what I meant. _You_ should now what you're doing and 
rc.shutdown tries its best afterwards. There is no real daemons 
dependency handling in Arch (probably because of KISS) so we can't 
expect it does always the right thing, but at least without the restart 
it would do in your example and that's better than nothing (random 
order) isn't it? :)