Cacti/PHP Problem Under Windows
Moderators: Developers, Moderators
Prolem solved
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 ?
"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 ?
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.
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.
Working with new PHP
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
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
Anyhow, here is what I tested with:
Windows XP / IIS6
Cacti 0.8.5
PHP 4.3.5 RC2
-Ian
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.
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.
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?
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 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?
IIS 5.0 CGI mode problem
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'
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'
my graphs are working now
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!
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!
**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...
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.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...
-Ian
Who is online
Users browsing this forum: No registered users and 0 guests