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.