Apache 2 follies

I was trying to get a pretty simple Apache 2 virtual host configuration together and for some reason Apache refused to start up. I tested the configuration with httpd -St and everything was fine. I started httpd with full debug reporting on (-edebug) and got no error messages. But apache would silently fail to start.

My general expectation is that programs will give feedback at the terminal if they fail, so I didn’t think it was necessary to check Apache’s logs while debugging configuration problems. But I was out of ideas so I fired up a tail -f /var/log/httpd/error_log and tried again. Sure enough:

[Sat Apr 08 16:22:00 2006] [error] (2)No such file or directory: could not open transfer log file /www/hosts/www.domain.com/logs/access_log.
Unable to open logs!

The logs directory didn’t yet exist. I created it and Apache started up just fine. Without it, Apache refused to run!

At first this infuriated me. But then I thought: maybe this is the preferable behavior for server software. It’s one less variable to worry about — if my website is up, I know that its logs are working.

Systems folks: what do you think? Should daemons refuse to run if their logs aren’t working?

Independent of if it runs or not, I think that Apache should give feedback at the console (in addition to the logs) when it isn’t starting properly. If I had restarted my daemon and gone to lunch, I would never have known that there was a problem!

1 Response to “Apache 2 follies”


  1. 1 Kevin

    I think Apache behaves this way because it’s usually started by an init script on a server. In that context it’s most convenient for Apache to communicate problems by logging them (since logs are probably being monitored for error messages, while the console isn’t) and return a nonzero exit code (which the script can detect and print a standard error message). Unfortunately you can’t perceive either of those things when you run apache directly.

    Personally I think that the inability to write to error_log is a justified reason to halt, but when other logs are not writeable the process should start, post an error message to error_log (and possibly to stderr too), and continue operating. In particular, if /var fills up over the weekend, I’d rather have my web server continue operating but stop logging accesses, than stop doing anything at all.

    On the other hand, a lot of ancillary things (like traffic monitoring) rely on Apache’s access logs, so maybe considering them to be optional just opens the door to hard-to-diagnose bugs in those programs.

Leave a Reply




Close
Powered by ShareThis