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

[Dave Reisner]

On Thu, Sep 02, 2010 at 01:53:20AM +0200, Kurt J. Bosch wrote:
> 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? :)
> 
> 

Isn't the KISS solution just to add the thing to the DAEMONS array?

We're clearly in disagreement, and this is getting a little circular.
I'm going to bow out from this gracefully -- the devs can resolve this
as they see fit.