Cacti/PHP Problem Under Windows

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

Moderators: Developers, Moderators

User avatar
Pumpi
Cacti User
Posts: 259
Joined: Wed Jan 14, 2004 3:23 am
Location: Germany

Prolem solved

Post by Pumpi »

Hi @ll,

"Workaround: use session_write_close() before the exec.

You can use session_start() after the call if you still need to write
session values. Reading doesn't require an open session."

Is the problem solved without CGI mode and with Cacti 0.8.5 ??

How can I implement the fix ?
infuseweb
Posts: 35
Joined: Wed Oct 29, 2003 5:30 pm

Post by infuseweb »

Tried the latest beta in ISAPI mode and hate to disappoint you, but it didn't work. Still maxing out the CPU. I'll try it in CGI mode and see what happens.

No dice in CGI mode either. The only time graphs act as if they're trying to do something is when I add the Everyone user to the CMD.EXE file. Then, I get the little "x" in each image. Without Everyone user assigned to the CMD.EXE, CPU usage goes to 100% and I have to do an iisreset to stop the process.

If there are some other permissions you adjusted, let me know. Maybe I'm missing something.
Guest

Post by Guest »

Sorry for 0.85, but it does not work.
Guest

Working with new PHP

Post by Guest »

I just grabbed the latest release of PHP and it appears to have resolved the blocking issue in ASAPI mode! Here's my combination on XP Pro:
  • Apache 2.0.48
    PHP 4.3.5 RC2
    Cacti 8.5
:D
raX
Lead Developer
Posts: 2243
Joined: Sat Oct 13, 2001 7:00 pm
Location: Carlisle, PA
Contact:

Post by raX »

Maybe we are talking about two different issues here. I have heard multiple reports that say 0.8.5 fixes the issue and a few that say it doesn't. The only issue this workaround might fix is the blocking problem with ISAPI mode. I do not remember this having anything to do with cmd.exe eating up all of the CPU.

Anyhow, here is what I tested with:

Windows XP / IIS6
Cacti 0.8.5
PHP 4.3.5 RC2

-Ian
infuseweb
Posts: 35
Joined: Wed Oct 29, 2003 5:30 pm

Post by infuseweb »

The Windows processor usage going through the roof was most likely because of CMD.EXE, which we've discussed here numerous times, I believe. I've confirmed on every machine that I've tested the same thing. Give CMD.EXE Everyone rights, and images appear to be trying to generate, but result in a broken image. Don't give CMD.EXE rights, and CPU usage goes to 100% when trying to view the charts.

I have been testing on Windows Server 2003 with IIS6, PHP 4.3.4 and both ISAPI/CGI mode. Currently I have things in ISAPI mode and have no luck. Let me try the latest RC of PHP and see if that helps.
infuseweb
Posts: 35
Joined: Wed Oct 29, 2003 5:30 pm

Post by infuseweb »

FINALLY!!! Progress. With the latest PHP RC in ISAPI, Windows 2003, and IIS6, I got things working. The downside. Had to give IUSR_ read/execute rights to CMD.EXE. NOT a good thing, but at least we've made a little progress.

EDIT: Is there a way perhaps we can copy the CMD.EXE file to a safer directory and execute it from there instead?
Krycek
Posts: 1
Joined: Tue Feb 03, 2004 11:39 pm

Post by Krycek »

infuseweb wrote:FINALLY!!! Progress. With the latest PHP RC in ISAPI, Windows 2003, and IIS6, I got things working. The downside. Had to give IUSR_ read/execute rights to CMD.EXE. NOT a good thing, but at least we've made a little progress.

EDIT: Is there a way perhaps we can copy the CMD.EXE file to a safer directory and execute it from there instead?
Same exact problem. Same exact config. Hopefully someone can figure out a solution...but your not alone! I'll keep working on it as well!
infuseweb
Posts: 35
Joined: Wed Oct 29, 2003 5:30 pm

Post by infuseweb »

Yeah, hopefully we'll get things worked out now. This is the closest I've been in 4 months to getting things working right and I'm thrilled! Cacti is really cool once you get to take advantage of the user management!
User avatar
Pumpi
Cacti User
Posts: 259
Joined: Wed Jan 14, 2004 3:23 am
Location: Germany

IIS 5.0 CGI mode problem

Post by Pumpi »

Running newest mysql, php, cacti version with IIS 5.0 and I get always following error when I try to reach the the cacti page:

Warning: mysql_connect(): Client does not support authentication protocol requested by server; consider upgrading MySQL client in C:\Inetpub\wwwroot\cacti\lib\adodb\drivers\adodb-mysql.inc.php on line 318

Cannot connect to MySQL server on 'localhost'. Please make sure you have specified a valid MySQL database name in 'include/config.php'
rich

my graphs are working now

Post by rich »

Did the upgrade from 0.8.4 to 0.8.5 and the no graph / graph lock up problem went away. Was exporting all the graphs to get at the data previously. Didn't want to mess with the CGI set up.

My config:

Windows 2000 with all service packs and patches loaded.
Apache 2.0.48
PHP 4.3.4
MySQL 4.0.16
Cacti upgrade from 0.8.4 to 0.8.5

I did end up deleting all of my data and starting from scratch. Before this the graphs were coming up empty for some reason. May have been something I did though. ( Yes I did move my data from the old dir )

Nice job Rax!! Program is getting better all the time!
BSOD2600

Post by BSOD2600 »

**Correction to Windows install guide**

Currently what it says, 6. In the c:\php directory, rename the php.ini-dist file to php.ini, copy it to c:\winnt, and make the following changes to the file:

What it SHOULD say, 6. In the c:\php directory, copy php.ini-dist file to c:\winnt, rename the to php.ini, and make the following changes to the file

I found out that when you have a php.ini file in the c:\php directory, it defaults to that file instead of the c:\windows one!! Thank goodness for Sysinternals Filemonitor to track this issue down...
raX
Lead Developer
Posts: 2243
Joined: Sat Oct 13, 2001 7:00 pm
Location: Carlisle, PA
Contact:

Post by raX »

BSOD2600 wrote:**Correction to Windows install guide**

Currently what it says, 6. In the c:\php directory, rename the php.ini-dist file to php.ini, copy it to c:\winnt, and make the following changes to the file:

What it SHOULD say, 6. In the c:\php directory, copy php.ini-dist file to c:\winnt, rename the to php.ini, and make the following changes to the file

I found out that when you have a php.ini file in the c:\php directory, it defaults to that file instead of the c:\windows one!! Thank goodness for Sysinternals Filemonitor to track this issue down...
Thanks for pointing this out, I will update the Win32 install document.

-Ian
Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest