something just not right ...

[guest]

if I run cmd.php through my web browser, it appears to execute ... or, at least I see the following information in my rrd.log (which I think is good):

06/14/2002 10:33 AM - CMD: /usr/bin/rrdtool update /var/www/html/cacti/rra/nw1_in.rrd --template nw1_in N:1603538768
06/14/2002 10:33 AM - CMD: /usr/bin/rrdtool update /var/www/html/cacti/rra/nw1_out.rrd --template nw1_out:nw1_out N:0.28:1306941771
06/14/2002 10:33 AM - CMD: /usr/bin/rrdtool update /var/www/html/cacti/rra/nw2_in.rrd --template nw2_in:nw2_in N:0.13:3413038314

the entry in my crontab is:

*5 * * * * apache php /var/www/html/cacti/cmd.php > /dev/null 2>&1

My CRON log shows it executing, but nothing appears in the rrd.log.

The next problem is the graphs aren't displaying any information (graph is there, but no data). If I read the above log information correctly, when I run it manually, it looks like it's applying data ... soo ...

What am I doing wrong? I'm sure I've done something wrong, I just can't figure it out.

[raX]

At first glace, your crontab line does not look correct. This may still work though (I'm not sure). Anyhow, yours looks like this:

*5 * * * * apache php /var/www/html/cacti/cmd.php > /dev/null 2>&1

It should look like this:

*/5 * * * * apache php /var/www/html/cacti/cmd.php > /dev/null 2>&1

See if that changes anything.

-Ian

[guest]

my bad ... that's a typo in the message ... my crontab is like you say it should be ... any other ideas? I'm running RH 7.3 and also compiled the latest version of PHP to fix some other issues.

[integr8er]

Getting data into the rrd files and graphs is sensitive to file and directory permissions.

Remember that the web browser runs as some user (httpd or apache) that needs read/write access to the rra and log directories and files therein.

Also, the user account that the cmd.php data collector script executes under also needs read/write access to the rra directory and files therein.

Also, another big thing I've seen in these postings is that the max value (defaults to 1) is often left at default (SOMETIMES/OFTEN/MOSTLY - ALMOST ALWAYS!!!) I wish the max value was defaulted to some HUGE number!!!!!!! hint hint hint ). If this is not changed, then the rrd files will not record the value given to it. My personal experience is that I make this value really big to get it out of my way. Setting this to some kind of thought out value probably makes sense for some situations. Maybe some other reader might speak up as to what sense might be applied to setting some sensible max value for some real world use.

Note that the log file produced by cacti and cmd.php is only a log of rrdtool commands passed to the system to execute. This same log file does not in any way show the execution status of the commands!! I specifically do not redirect stderr for cmd.php to /dev/null. You never see the failed commands error messages when you send it all to /dev/null. Send the output to a log file in the same directory as the cacti rra.log file. Then you can see these errors and help yourself in debugging. However, you sholuld then ensure that you are doing something to truncate or rotate these log files at some useful interval. I do this weekly.

You may also find other error messages in the log files for the web server as various commands fail while executing under the web server. Examples of this are needing read access to rrd files to generate graphs and needing write access to the rrd files when you change some attribute of an rrd file from the cacti web gui that results in a rrdtool tune command being executed [when you check the update rrd file box] and so on....

[guest]

thanks for the info ... i think i'm on to something ... i omitted the dev/null statement and saw the error ... and it looks familiar:

Fatal error: Call to undefined function: mysql_connect() in /var/www/html/cacti/include/database.php on line 19

i was getting this error in the web browser before i downloaded the latest version of PHP and compiled it. now i'm getting it at the command-line level ... the date on the executable doesn't match with the date i did the install ... so, i'm guessing that the executable binary is my problem ... i guess now i need to read thru my PHP documentation and figure out how to compile that binary.

[guest]

woohoo ... collecting data ... at least for the SNMP stuff ... now ... if i can just figure out while the ping scripts aren't working ...

[RandomWelshBloke]

A problem I had with RH7.2 (could be the same for you in 7.3) was the ping.pl script

Just add -U to the ping command in that script.

Some quirk of RH I've been told.

Random

[guest]

ya ... thanks for that last bit of info ... i ended up searching thru the forum and found that there is indeed a problem with Redhat 7.3 and the perl script ... rax posted a new version of the script in that thread ... so i grabbed it and all is indeed good.

i even fiddled with the weatherbug script and am currently using it ... now for stock quotes