httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mikey <>
Subject [users@httpd] Apache2 randomly displaying older versions of pages
Date Sun, 16 May 2004 00:58:34 GMT
This is long but please stick with me. I'm trying to give as much information as I can think

We have run mod_perl1 and Apache1 since about September and it has seemed extremely stable
and very fast. We use handlers for our sites and HTML::Tmojo (
to display the pages. I'm not sure if I should be submitting this to the apache mailing list
or the mod_perl mailing list, but I thought I'd try here first.

Recently we've switched to Apache2 and mod_perl2. At first all seemed well, but when working
on some handlers we started encountering really strange issues. First let me show you how
we have Apache2 configured:

PerlModule Apache2 
#PerlModule Apache::Reload
#PerlInitHandler Apache::Reload
#PerlSetVar ReloadDebug On
#PerlModule Apache::ServerUtil

LogFormat "%t \"%r\" %s %P %p %X" labdebug

<VirtualHost *>
    DocumentRoot /app/test/Lab01/htdocs_lab01

    CustomLog /var/log/apache/access_log-labdebug labdebug

    [Various configuration...]

    <Location /mcp_admin>
        SetHandler perl-script
        PerlResponseHandler Lab01::MCP::AdminHandler

Apache::Reload is only commented because we were testing last night. I should also mention
that all of our handlers have been updated how the "Migrating to 2.0" page on
says we should. If you need an example of a handler we have, I can provide that.

Before giving an example of our problems, note that every time I say "restart", I mean that
we stopped the server with bin/apachectl stop, netstat -an | grep 80 | grep LISTEN, ps aux
| grep httpd to make sure it was fully stopped, then start it with bin/apachectl start.

Now let me give you a few examples of the issues we are having. In our MCP::AdminHandler (which
worked flawlessly until the apache2/mod_perl2 upgrade mind you), we could create an error
by adding an invalid statement somewhere in the beginning of the file. I would restart apache,
and go to, and it would be broken (500 error) as it should. Refreshing
numerous times, and it would eventually (completely random) actually work (200). Sometimes
it would work permanently after it worked once, and sometimes it would only work once then
go back to not working.

You'll notice the LogFormat line pasted above. Here is a bit from that log:
[15/May/2004:00:25:43 -0600] "GET /mcp_admin HTTP/1.1" 500 13408 80 -
[15/May/2004:00:25:49 -0600] "GET /mcp_admin HTTP/1.1" 500 13409 80 -
[15/May/2004:00:25:50 -0600] "GET /mcp_admin HTTP/1.1" 500 13410 80 -
[15/May/2004:00:25:52 -0600] "GET /mcp_admin HTTP/1.1" 500 13415 80 -
[15/May/2004:00:25:53 -0600] "GET /mcp_admin HTTP/1.1" 500 13411 80 -
[15/May/2004:00:25:54 -0600] "GET /mcp_admin HTTP/1.1" 500 13412 80 -
[15/May/2004:00:25:55 -0600] "GET /mcp_admin HTTP/1.1" 200 13408 80 +
[15/May/2004:00:25:56 -0600] "GET /img/icon_file_blue.gif HTTP/1.1" 200 13409 80 +
[15/May/2004:00:25:56 -0600] "GET /img/icon_x_blue.gif HTTP/1.1" 200 13410 80 +
[15/May/2004:00:25:56 -0600] "GET /img/icon_bookmark_blue.gif HTTP/1.1" 200 13415 80 +
[15/May/2004:00:25:56 -0600] "GET /img/icon_triangle_blue.gif HTTP/1.1" 200 13408 80 +
[15/May/2004:00:25:56 -0600] "GET /js/wz_tooltip.js HTTP/1.1" 200 13409 80 +

On furthur investigation, we edited a tmojo file (think .php) and made a change to add a variable
passed by the handler inside some brackets while the server was running. Refresh the page,
the brackets would appear but the variable inside it would not because Apache::Reload is not
turned on. That worked as it should the first time. We restart the server and the timestamp
appears inside the brackets. We thought we were getting somewhere at this point (we used a
timestamp so that we could see when that httpd process had loaded it). Then after a few refreshes,
we came to a page without the timestamp in the brackets, which seems to mean that somehow
there is a process still alive that had an OLD copy of the handler, same as above with MCP::AdminHandler.

I think the most weird part is that Apache2 would give a 500 on STATIC CONTENT once errors
started happening. Again random, if you keep refreshing a page with a broken handler, it would
eventually give you an old working version of the handler so you would be able to view the
site, but random images on the page would not display. For instance we use one little tiny
arrow image in many places, some of them would display and some would not. Looking at the
logs, there are IMAGES returning a 500 error. These images are not served by a handler, but
are in DocumentRoot directories: - - [14/May/2004:15:22:25 -0600] "GET /ls/static/ls1/images/tabs_far_left.gif
HTTP/1.1" 500 2131 - - [14/May/2004:16:53:47 -0600] "GET /img/icon_x_blue.gif HTTP/1.1" 500 2112 - - [14/May/2004:22:44:09 -0600] "GET /img/icon_triangle_blue.gif HTTP/1.1"
500 2065

After a while we thought it might be something with KeepAlive because it seems as if some
httpd processes are somehow staying alive but not showing up in ps aux, and thus serving old
versions of a handler. So we turned KeepAlive Off, and it yielded the same random results.

The problem (as far as we can tell) does not happen until you encounter an error for the first
time. If Apache2 is restarted, everything will work perfectly until you go to a page with
an actual broken handler, then all this starts to happen.

We're reverting back to Apache1 and mod_perl1 today because we have much to do and cannot
be slowed down by this, but would really rather be running Apache2/mod_perl2, so if you have
any ideas at all, it would be very helpful.

Thank you for taking the time to read this!


The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:> for more info.
To unsubscribe, e-mail:
   "   from the digest:
For additional commands, e-mail:

View raw message