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? :)
