Cacti polling cycle failed

Post support questions that relate to the Windows 2003/2000/XP operating systems.

Moderators: Developers, Moderators

Post Reply
keever
Posts: 19
Joined: Tue Aug 22, 2006 6:10 pm

Cacti polling cycle failed

Post by keever »

Operating System: Server 2008 SP2 x64
Webserver: IIS 7
Cacti: cacti-0.8.7e
Spine: spine0.8.7e
MySQL: mysql-5.1.47-winx64
PHP: Version 5.2.13
RRDTool (Cygwin or Win32 version): Win32
Net-SNMP: not installed
Cygwin (cygwin1.dll version): 1000.5.0.0
Plugin Architecture: unsure of this category.. fastcgi?

I was following the Cacti configuration instructions at this url:

http://bsod2600.home.comcast.net/~bsod2 ... ndows.html

On step 13, it says to log in with the user meant to run the scheduled task, and verify that the cacti polling cycle works by running this at a command prompt:

php c:\inetpub\wwwroot\cacti\poller.php

When I ran that command, a red window pop up box came up with this error:

"This application has failed to start because php_pdo.dll was not found. Re-installing the application may fix this problem."

After I clicked ok to the textbox, it reappeared 2 additional times. Also, I have created a few graphs for two firewalls, and none of them are populated. I have created a scheduled task as described in the above how-to, so the polling cycle definitely fails.

Should I reinstall php? Should I find that missing dll and put it into c:\php?
keever
Posts: 19
Joined: Tue Aug 22, 2006 6:10 pm

Post by keever »

Also:

When i navigate to Settings > Paths, all of the paths except the Cacti Log File Path have a red label reading:

[ERROR: FILE NOT FOUND]

The paths and filenames are in face correct, and the file does exist at the path specified. It tried switching to backslashes for the path, and that had no effect. What gives?
User avatar
BSOD2600
Cacti Moderator
Posts: 12171
Joined: Sat May 08, 2004 12:44 pm
Location: USA

Re: Cacti polling cycle failed

Post by BSOD2600 »

keever wrote:Should I find that missing dll and put it into c:\php?
Depends.

Cacti doesn't normally need that php extension, so I'd say disable it in php.ini. If other websites need that extension, then yes find the dll and properly install it. In general, installing ALL of the php extensions via the installer is a bad idea -- only install the ones you need.
keever wrote: The paths and filenames are in face correct, and the file does exist at the path specified. It tried switching to backslashes for the path, and that had no effect. What gives?
The IIS_USR group doesn't have read/execute permissions on those files/folders -- this is what is being tested on the Settings->Paths page. Sysinternals processmonitor will show all the dirty details what is going on.
keever
Posts: 19
Joined: Tue Aug 22, 2006 6:10 pm

Post by keever »

I have followed the directions to use the processmonitor utility from this link:

http://forums.cacti.net/viewtopic.php?t=26165

Here's the problem: I'm finding NO "access denied" or any "denied" strings in my captured output. But, the cacti still shows


[ERROR: FILE NOT FOUND]

for every path except the "D:/cacti/log/cacti.log". I have manually confirmed that IUSR and IIS_IUSRS both have read&execute for all the listed paths.


The php problem was taken care of by commenting out all the unneedd php extensions. Now the command "php c:\inetpub\wwwroot\cacti\poller.php" now just ends with no output. No graphing data has been stored, but there are no errors in the cacti logs or php logs. I don't know how to troubleshoot the problem further.

Why on earth does cacti return the [ERROR: FILE NOT FOUND] message for folder that processmonitor and my own eyes confirm that IUSR and IIS_IUSRS have read&execute perms? IT's like the cacti GUI is stuck with a false reading of my OS perms. I tested this by removing read&execute from the "d:\cacti\log\cacti.log" and it still returned the [OK: FILE FOUND] message. It's like the settings on the GUI are disconnected from what my OS has.
User avatar
BSOD2600
Cacti Moderator
Posts: 12171
Joined: Sat May 08, 2004 12:44 pm
Location: USA

Post by BSOD2600 »

The Settings->Path page invokes the web service's user account. In the case of windows 2008, this IUSR and IIS_USRS. In order to test the applications in those paths, the cacti website must launch cmd.exe with the IIS user credentials. Since it's unable to launch cmd.exe and/or read the various binaries in the specified paths, it returns FILE NOT FOUND.

In the process monitor traces, do you see cmd.exe getting executed and running?

How about you save a trace to file... to limit the amount of noise, clear the process explorer view, click refresh on the cacti Paths page, and then stop process explorer logging. Save the results to file and attach for review.
keever
Posts: 19
Joined: Tue Aug 22, 2006 6:10 pm

Post by keever »

nothing happened when i refreshed the settings/paths page. But a whole bunch of output barfed out when the scheduled task ran. attached is the output file.
Attachments
Logfile_7.19.10.zip
(213.07 KiB) Downloaded 124 times
keever
Posts: 19
Joined: Tue Aug 22, 2006 6:10 pm

Post by keever »

more information. Here's the output from the "Graph Debug Mode"
RRDTool Command:

C:/rrdtool/rrdtool.exe graph - \
--imgformat=PNG \
--start=-86400 \
--end=-300 \
--title="SonicWall C - Traffic - X1 (WAN)" \
--rigid \
--base=1000 \
--height=120 \
--width=500 \
--alt-autoscale-max \
--lower-limit=0 \
--vertical-label="bytes per second" \
DEF:a="D\:/cacti/rra/sonicwall_c_traffic_in_12.rrd":traffic_in:AVERAGE \
DEF:b="D\:/cacti/rra/sonicwall_c_traffic_in_12.rrd":traffic_out:AVERAGE \
AREA:a#00CF00:"Inbound" \
GPRINT:a:LAST:" Current\:%8.2lf %s" \
GPRINT:a:AVERAGE:"Average\:%8.2lf %s" \
GPRINT:a:MAX:"Maximum\:%8.2lf %s\n" \
LINE1:b#002A97:"Outbound" \
GPRINT:b:LAST:"Current\:%8.2lf %s" \
GPRINT:b:AVERAGE:"Average\:%8.2lf %s" \
GPRINT:b:MAX:"Maximum\:%8.2lf %s\n"

RRDTool Says:

ERROR: opening 'D:/cacti/rra/sonicwall_c_traffic_in_12.rrd': No such file or directory
keever
Posts: 19
Joined: Tue Aug 22, 2006 6:10 pm

Post by keever »

bp
User avatar
BSOD2600
Cacti Moderator
Posts: 12171
Joined: Sat May 08, 2004 12:44 pm
Location: USA

Post by BSOD2600 »

keever wrote:nothing happened when i refreshed the settings/paths page. But a whole bunch of output barfed out when the scheduled task ran. attached is the output file.
Shame, I don't run a x64 OS so can't open the file :(

If nothing showed up... then I'm guessing it's a lack of proper permissions on cmd.exe. What have you set on that binary?
keever
Posts: 19
Joined: Tue Aug 22, 2006 6:10 pm

Post by keever »

C:\Windows\System32\cmd.exe permissions:

IUSR: read&execute, read
IIS_IUSRS: read&execute, read
task user: read&execute, read

So all the permissions are correct. I've deleted my cacti database, removed the cacti web root, and unzipped another fresh install of cacti to the web root and then recreated the database. When I read the cacti Installation Guide part of the new install process, all the paths are red with [NOT FOUND] next to them *EXCEPT* for the cacti log file path. Nothing has changed and I have reconfirmed that I have the right permissions on all the right dirs/files more times than necessary, and then backed it up with processmonitor not finding any "access denied". Also, if all the perms were wrong on the RED [NOT FOUND] paths, why would the cacti log path work? That path has exactly the same perms (pluss modify) as all the others. It makes no sense that the cacti log path would be working, but all the others aren't able to be "found".

Now, I was suspicious of this specific server 2008 OS build so I installed server 2008 R2 on a different server, and then followed the installation docs AGAIN. I still have the same issue with all the paths not being readable/writable. Thus this isn't an incidental issue with just one of our servers. It's not because the server was previously used for other sites, and had other 3rd party software installed. This problem is now reproducible. The only thing that I can think of that I deviated from your installation instructions (http://bsod2600.home.comcast.net/~bsod2 ... ndows.html), is that I didn't want to use the c:\inetpub\wwwroot directory for my cacti install. I just put the cacti installation on a different drive and path (d:\cacti). It would be completely ridiculous if the web root path made a difference in the functionality. A web root directory should be arbitrary, and it would be lame as hell if it had to be static for cacti to work.

I'm nearing wits end troubleshooting this on a winbox. I should have just installed a *nix distro and config'd it that way. If I can't get this perms issues resolved, I'll be of the opinion that the cacti port onto a win machine is too buggy and unreliable for any sort of production use (or non prod even).
User avatar
BSOD2600
Cacti Moderator
Posts: 12171
Joined: Sat May 08, 2004 12:44 pm
Location: USA

Post by BSOD2600 »

Hmm, well I fired up my windows 2008 VM and used my cacti installer... but it only gets an useless error 500 page and PHP crashing (even though a basic phpinfo page works) with IIS. Guess I need to some additional digging into that before the next release...

The Apache install worked just fine (including all of the Settings -> Paths).
keever
Posts: 19
Joined: Tue Aug 22, 2006 6:10 pm

Post by keever »

which cacti version did you use on the 2008 VM? Cacti 0.8.7e or Cacti 0.8.7f? What you described sounds familiar to a problem i had with Cacti 0.8.7f that you actually helped me with about a month ago.
User avatar
BSOD2600
Cacti Moderator
Posts: 12171
Joined: Sat May 08, 2004 12:44 pm
Location: USA

Post by BSOD2600 »

keever wrote:which cacti version did you use on the 2008 VM? Cacti 0.8.7e or Cacti 0.8.7f?
The latest in my windows installer, 0.8.7e
keever
Posts: 19
Joined: Tue Aug 22, 2006 6:10 pm

Post by keever »

I haven't been able to find in this forum, or in any how-to docs, the correct permission for apache2.2 installed on a windows OS. I keep on getting, "Forbidden You don't have permission to access / on this server.". The Apache service runs as the local system, which has full perms on my cacti web root dir. So what user do I give perms to?
keever
Posts: 19
Joined: Tue Aug 22, 2006 6:10 pm

Post by keever »

nevermind, I remembered that I have to change the line in the httpd.conf file to allow all instead of deny all.
Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests