I think the topic says it all... Is this maintainance or is there a problem as every monday FT isn't available till about 2pm CET for me. It looks like it's related to Omni's "NO"...

Thanks,

Scott

It's an irregular problem caused by the script that rotates the webserver logs. I tracked the problem this weekend. We'll have a fix in place before next weekend. (A short period of downtime for log rotation is unavoidable, but this script problem causes a longer downtime -- sometimes.)

Thanks for the reply John and as always a big thanks to you and your fellow FT collegues!

Thanks very much, John!

I guess that I'll let you in on a little secret that ITYT and other sites without downtime use.

Log rotation downtime is completely avoidable. After all, we'd all be pretty mad if we couldn't check in for a flight because they were rotating the logs or something, right?

Your problem sounds like you're having your web server (apache) directly write the logs to a file. This is suboptimal since you want apache's duties to be restricted to purely serving requests to web clients. Removing apache from this task helps both reliability and speed.

Write a program that can receive log input via stdin, buffer the data to avoid unnecessary disk writes, and then writes the log files appropriately. The program should be able to detect when the date changes (or the week, if that's how you rotate your logs), flush and buffered data to the old file, open the new file, and start buffering data for the next write to the new file. Then, have your webserver log to that program, not a file. Apache should output log data via stdin to that program and you'll be set.

Voila, your site will never go down for log rotation and web hits are being served faster than before.

Cheers.


------------------
daniel baker -- [email protected]
Reliable, fast, and unmoderated forums at ITYT.

[This message has been edited by dbaker (edited 02-11-2002).]