Comment 2 for bug 23938

Hmmm... Well, it's good to hear that it's a config file.. but I think doing a
hard restart is really bad. I do understand your concern that the server going
down at 6:30 would be really bad though. I think with an apachectl restart.. if
they broke their config file, the server would go down aswell. Verses graceful
if there's a broken config file, it WON'T graceful at all (EG: staying up under
the working config)

Maybe it's the "other guys problem" in me that says it should be a graceful
restart, but I have to imagine the majority of users don't have busted/broken
apache plugins in their production environments. So I would assume this apache
crashing problem affects the minority of users. The hard restart at 6:30am,
affects ALL ubuntu users. Since apache is one of the premier services that will
be run on ubuntu servers, I can't imagine it would be acceptable to need to go
down to rotate the logs.

I realize I can change this by modifying that file, and I certainly have... but
there's NO WAY anybody else is going to ever notice this until it's too late.
The only reason why I noticed this is because an API call (Business logic call
over SOAP) was running at 6:30am, and got terminated mid-communiucation. This
left the database of that site in a damaged condition. (These servers are not
in production for us yet.. but it would have broken any of our production
systems if we had ubuntu in production).

One of two things should be done:
* Ask the user when installing/updating the apache, if they want everybody to be
booted at 6:30am, or possibly risk apache crashing if your apache is unstable/broken
* Write a script that checks for apache crashing, and notify the administrator
that their system is broken

The script would work something like this:

if (Check the pid file exists) {
 if (Check the apache process running)) {
  apachectl graceful
  sleep 10
  if (!(Check the pid file exists) || !(Check the apache process is running)) {
   apachectl start
   Email administrator saying apache crashed during log rotate, and the issue
needs to be delt with immediately (EG: SSL services restarted... etc.)
  }
 }
}

I feel like the latter solution is the best... since it should take care of your
concern that apache will be down going forward after the log rotate.