dcsimg

Apache Guide: Logging, Part 2 -- Error Logs Page 3

By Rich Bowen (Send Email)
Posted Aug 28, 2000


Without logs, it would be very difficult to troubleshoot most CGI programs, because running the program from the command line is a rather different environment than running it from a web server.

Nine times out of eight, when someone complains on a mailing list, or on a newsgroup, that they are having CGI problems, and are getting a page that says something like "Internal Server Error", they have not looked at the logs, or are unaware of their existence. Very frequently, a glance at the logs will tell you exactly what the problem is, and tell you how to fix it.

How Do I Watch the Log?

Often, I'll tell people that I watch the server logs while I am developing, so that I know immediately what is going wrong. This is frequently met with a blank stare. At first I assumed that this meant "well, of course you do." Later I discovered that it usually means "I have no idea how one would do that, but I'm not about to admit it."

OK, so here's how you do it. Telnet into the machine on which your Apache server is running, and type the following command:


        tail -f /usr/local/apache/logs/error_log

This will show the last few lines of your log file, and, as lines are added to the file, it will show you those as they happen. Neat, huh?

What, you're running on NT. No problem. There are a few ways around this. There are a variety of Unix tools packages available for Windows. My personal favorite is one called AINTX, which you can find at http://maxx.mc.net/~jlh/nttools/index.htm

Another alternative is to use the following Perl code, which uses a module called File::Tail

        use File::Tail;
        =File::Tail->new("/some/log/file");
        while (defined(=->read)) {
                print "";
        }

Whatever your method, it's extremely good practice to keep several terminal windows open, with your error log tailing in one window, and your access log tailing in the other, while you work on your site. This will tell you what is going on as it happens, and so you know about problems before the customer has a chance to call you about them. That way, you can either answer the phone with "yes, I know, and it's already fixed," or, perhaps, not answer the phone at all. ;-) Shh. Don't tell my customers I said that.

What's Next?

Next week, I'll be talking about custom server logs--how you can build logs that contain only the information that you are interested in, and nothing else.

After that, we'll discuss log processing--how to glean useful information out of these log files.

Finally, we'll talk about redirecting your log files to a process, rather than to a file, so that you can process that data as it is being generated. This will cover such things as sending your logs to a database, and perhaps sending email to the sysadmin when something particularly nasty happens, and other things like that.

And whatever else people write me about between now and then, I'll try to tackle as well. Send me a note at ApacheToday@rcbowen.com, and I'll see what I can do.

Want to discuss log files with other Apache Today readers? Then check out the PHP discussion at Apache Today Discussions.

Page 3 of 3


Comment and Contribute

Your name/nickname

Your email

(Maximum characters: 1200). You have characters left.