Cheshire Cat Computing

Hello !

Thirst of all, your software is great and makes reporting easy !

Today I noticed a strange behaviour.

I use v2.17a / RRDtool 1.2 on a W2k3-Server (apache 1.2) and all works fine but archived RRDs aren't displayed correctly:

An archived RRD shows only values if these are in the timerange of the current day. So yesterdays daily graph displays correct but a daily graph from one week ago is filled grey. The archiving (rrdarchive.pl) works correct, the archived rrds contains values.

In the old version (v2.16 / RRDTool 1.0.40) the display of archived graphs worked without problem.

Has anybody the same problem or was there a change in v2.17a concerning display of archived RRDs ?

Best regards

Thomas

In 17a, if (for any reason) trouters2 cannot access the archived RRD file, then it uses the live one.

This means that when you try to access yesterdays graph,but the rrd file is not accessible, it will use the live one which coincidentally still holds data back that far, so it appears to work.

I've tested some things again, and it works here. So, what could be going wrong?

Well, a debug message comment appears hidden at the bottom of the main page if you attempt to access an archive that cannot be found. The archives for yyyy-mm-dd for an RRD file /path/file.rrd are lookd for in /path/archive/yyyy-mm-dd/file.rrd. This may be getting confused if you use the Directory[] definition to define additional subdirs. Can you check to see where your file.rrd archives are kept, and if this matches? Another possibility is that you are running in cached mode (with mod_perl or speedycgi), and the dates have been cached, but subsequently the archived .rrd files have been deleted.

Can you first check the location of your .rrd file, whether you use Directory[] or not, and the location of the archived copies of the rrd file. Also, check that the directory is readable and executable by the web server and the files are readable. It is possible that you have read to the directory but not to the file, or read but not execute to the directory (unlikely).

_________________
Steve Shipway
UNIX Systems, ITSS, University of Auckland, NZ
Woe unto them that rise up early in the morning... -- Isaiah 5:11

Thank you very much for your quick response !

Yes, I use the Directory[]-directive (one directory for each router/switch) and the archive-folder is stored under this device-specific-directory:

C:\reports\html > the main folder where all device-specific-foldes for rrds are stored (the MRTG WorkDir)

Directory[_]: a78haa011.netge.wienkav.at > the entry in the MRTG-config-file for a device

Under this subdirectory the archive-folder exists and in the archive-folder the dated subfolders for the archives are present (with all the archived rrds in them).

Now I found out that it has something to do with caching (I use modperl):

When I restart the Apache-process and display an archived rrd the graph is created correctly. When I open another archived rrd (for example the day before the first one) the graph is filled grey (if there are no values in the rrd). After restarting Apache displaying the last rrds works correctly, too.
After that I disabled caching for the webserver and now all archived rrds are displayed like they should ! Funny ?

I use the "cache = yes" function in routers2.conf and following entries in httpd.conf:

LoadModule perl_module modules/mod_perl.so

<Files routers2.pl>
SetHandler perl-script
PerlResponseHandler ModPerl::Registry
Options +ExecCGI
Perloptions +ParseHeaders
</Files>

<Files routers2.cgi>
SetHandler perl-script
PerlResponseHandler ModPerl::Registry
Options +ExecCGI
Perloptions +ParseHeaders
</Files>

Is there something wrong with my caching-configuration ?

Thomas

I think the problem may be with the way routers2 handles caching.

Here, I use speedycgi, which will cause a processing thread to respawn after a certain time or number of iterations (meaning that it respawns overnight, when the new archives are created). mod_perl, however, NEVER respawns until Apache restarts. This means that if the cache gets out of synch it never notices.

Now, there are a number of age tests to make sure .cfg files get reloaded if they change (which fixes the problem for mod_perl), but I don't have this set up for the routers2.conf caching, nor for the archive-dates caching, and so it appears that mod_perl people will add new archves but routers2 doesnt notice them until Apache is restarted. Similarly, changes to routers2.conf will probably not be noticed until Apache is restarted.

This is clearly a bug... err, I mean, a 'feature' . So, in v2.18, I will add some extra checks to invalidate the cache of routers2.cgi if the file is changed since the last read, and also to invalidate the archive dates cache is the archive directory has a modify time since the last read, which should solve the issue.

In the meantime, I can only suggest one of
1) disable caching in routers2.conf. This will slow things down, especially if you have a lot of .cfg files
2) restart Apache (hence reinitialising the routers2 mod_perl threads) every night - maybe not practical
3) switch to speedycgi (unix only)

If this is causing major issues then please keep bugging me and I'll send you a beta with the fix. I'm off on holiday tomorrow for 5 weeks, though, so things will be held up until then.

Thanks for helping to track this one down, its a complex set of circumstances needed to trigger it which is why it avoided the testing.

_________________
Steve Shipway
UNIX Systems, ITSS, University of Auckland, NZ
Woe unto them that rise up early in the morning... -- Isaiah 5:11

Hi !

In the meantime I will leave caching disabled (caching is a nice feature but the correct display is worth the slower performance).
Yes, it would be very nice if you can provide a fix before version 2.18 !

Thank you very much for the quick clarification of this issue !

Have a nice holiday !

Thomas

I have a fix now. If you want to patch it yourself, the instructions are in the appropriate thread in the 'development progress' forum.
http://www.steveshipway.org/forum/viewtopic.php?t=1078

However, I can email a copy of 2.18beta2 if you'd prefer. Please email me directly to request if you (or anyone else) needs this.

_________________
Steve Shipway
UNIX Systems, ITSS, University of Auckland, NZ
Woe unto them that rise up early in the morning... -- Isaiah 5:11

_________________
Steve Shipway
UNIX Systems, ITSS, University of Auckland, NZ
Woe unto them that rise up early in the morning... -- Isaiah 5:11

_________________
Steve Shipway
UNIX Systems, ITSS, University of Auckland, NZ
Woe unto them that rise up early in the morning... -- Isaiah 5:11