On 23/06/10 10:04, Srdjan Todorovic wrote:
Do you see any similar report in Apache's bug tracking system?
Because...*any* crash is a bug.
I should be more careful with phrases like "crash", it's a bit too subjective.
To my mind, if I have a running server, and make a config change (*any* change, could be complete garbage), then the sequence: apache2 -t /etc/init.d/apache2 reload .. should either error at the -t test, or should be running after the reload.
I *thought* that a reload basically started a new thread with the new configuration, and as the old thread(s) finished handling their current connections they terminated and new threads started up as necessary. If that (vague) picture is correct, then if the first thread is unable to start then the rest should continue as they are and an error be reported, rather than the other threads continue to stop. And this should be the case regardless of whether the configuration has been tested.
Over the years I have seen several things trigger this. Someone starting to configure a new virtual host, not finishing the job but leaving the config file in an invalid state, then the server dies when logrotate causes a reload sometime in the night (albeit that a -t test would probably have warned about it if it had been used).
I'm not sure that the spec of the -t test is to catch *every*thing that might cause Apache not to run, nor do I think that Apache's reload command is intended to cope with a mis-configuration (I just think it should!). So I'm looking for an alternative web server that thinks differently about it's responsibilities, like (for example) trying harder to compartmentalise different virtual hosts so that they're less able to interfere with each other.
There may be a case to file an Apache bug against the -t test not picking up the specific certificate problem, though.