Jason Chu said: >> A bad solution is not always an improvement over no solution. I think >> basing a daemon stop order on time is an inherently bad idea. It would > ------------------- > This is where I disagree. Please convince me otherwise.
I assume you mean you disagree with the latter portion of the phrase, namely 'basing a daemon stop order on time is an inherently bad idea'. I made a first attempt. Let me try to rephrase it. Consider a server system. The system has a reasonable amount of uptime. At first boot, the following daemons start in a time based ordering. a) iptables b) network c) nfs d) ssh e) mysql f) apache At some point late in the night, you fiddle with your iptables config, manage to lock yourself out through ssh. Being a smarty, you didn't save it. So you login locally, and restart iptables, loading the default ruleset. You fix it, and save it. Your order now is: b) network c) nfs d) ssh e) mysql f) apache a) iptables If you were then to shutdown for reboot, your nfs mount would hang, because iptables would shutdown first...giving you a default allow policy. This might be ok, becuase of the speed at which things occur..but for a short period of time, you would have a network up with default allow privs. If you modified your iptables script to use default deny (safer), then your nfs mount would still be hanging. Pick your posion. A server with no firewall but working network (depending on the number of daemons shutting down, this could be 'live' from anywhere to a few seconds, to many seconds. Like I said, with the speed at which things are coming down..likely not a big issue.. *likely* not... Let us continue further.. Assume that you restart mysql somewhere down the line..to clear memory or some such thing. You now have. b) network c) nfs d) ssh f) apache a) iptables e) mysql Which isn't all that bad. You will have the potential for some scripts running under apache to yield a 'no db' for a short period of time, before apache shuts down, and people attempting to connect are either rerouted to an up host (if you are load balancing apache), or they get a 'server not responding' message of some kind. This is only a simple example with a few daemons. Daemons that 'loosely' rely on each other to be running. The loose coupling doesn't force you to restart daemons in appropriate order, and timestamps would then be off. Stronger coupled daemons would likely exhibit 'better behaviour', but not all daemons are as tightly coupled (which is a good thing). I am sure people can come up with a better example than I can as to loosly coupled daemons being restarted on a long running server causing problems at shutdown.. _______________________________________________ arch mailing list [email protected] http://www.archlinux.org/mailman/listinfo/arch
