Monday, August 17, 2009

Multiple PHP in a machine blues

I am compiling PHP's source code and a PHP extension (apc). The reason for not using packaged version of PHP is that there is another critical application running in the server, with its own PHP version, and we don't want to risk incompatibility issues forcing the application run with a different PHP version. Meanwhile I need PHP compiled with debug flags, and also with gd enabled and apc extension for another application. I prefer Debug flags to be enabled because we're testing this whole stuff and don't want to be in the dark when error (s) cropped up (previous set of PHP-apache-oci8 triad sometimes issued segmentation faults but we don't now the source of the errors).

The problem is, that the apc Makefile won't use the debug flag set during previous PHP compilation. It turns out that we must be very careful that:
  • the phpize being used is from the correct PHP compilation (I deleted the scripts/phpize and scripts/php-config after changing PHP's configure parameters, then invoke make install on PHP)
  • no other phpize or php-config is being run, especially by setting the PATH environment variable so the path to the correct phpize/php-config is the first directory listed in the PATH.
The second item is blocked me for some time, I didn't realize that the phpize - configure - make phase invoked php-config plainly (using the PATH). Because there is several PHP installation in the system, the php-config being run is from the other installation (the root administrator installed the other PHP binaries in the normal location such as /usr/local/bin).

Munin, again

More problems come when I'm just starting to use Munin-Node to monitor several Windows 2003 servers :
  1. the memory value reported by Munin-Node are all wrong. The sum of app and unused is not related to total physical memory installed in the servers. It turns out that the Windows API used returns 64-bit values, and simple change to the format specified fixes the problem.
  2. external plugin doesn't work. Turns out that the external plugin must not print the trailing newline when invoked by 'name' argument, and it also must prints a line of '.' after each 'config' and 'value' (or default) invocation.
  3. after several days of running, external plugins stopped working. I used sysinternals' process explorer in the server, and found out that there is some chance that external plugin invocation doesn't close the listener thread. After a few days the unclosed threads became too much and prevent the Munin-Node service from spawning new external plugins.

Thursday, August 6, 2009

Munin-Node 1.5 with correct memory plugin

Munin is a solution to monitor servers. It shows graphs of some important server's system parameters, such as disk free space, cpu utilization, memory usage, network traffic, and even the HD temperature. Munin requires an agent, called Munin Node, installed at the server (you must be root or administrators to do this). Of course, there is a specific Munin Node to be installed for each operating system. On Ubuntu systems, there is munin packages in ubuntu's repository. Meanwhile Jory Stone created Munin Node for Windows, and I'd be needing that because some of the servers used at my workplace is powered by Windows Server 2003.
I read the postings at jory's Munin Node site, and seems that memory plugin must be patched in order to have visible memory graphs. I've downloaded the source code from jory's site, then I followed the instructions to fix the memory plugin (uncommented few lines in MemoryMuninNodePlugin.cpp), and the next task is to compile the whole thing.
A simple thing, compiling, is not as simple as it seems.
First, the vcproj file is for VS 2008. I'm using VS 2005. After editing the version part of the file, the project file could be opened. Next, netfw.h couldnt be found. A few googling back and forth found some netfw.h, and I downloaded it with icftypes.h (look here). Then, msi.lib seems to be missing (I'm using VS 2005 which lacks that file). I am forced to download Platform SDK, and I choose only windows installer SDK to install (minimize download volume). Well, now I have a fresh munin-node.exe. But wheres that upload button in blogger... Oh, blogger doesn't allow us to upload files.
So i upload the executable in my own site at google.
It seems that, no easy deployments for executables compiled in VS 2005 - we either must link to C Runtime (CRT) static library, or link to CRT DLL and use some mechanisms to ensure the DLL will be installed using Windows SxS (side by side) mechanism. The mechanisms include making the user installed the VC Runtime redistribution or include the CRT Merge shared module into a MSI-packaged installation format.
I compiled it once more and this time packaged the executable in .MSI format (seems that the vdproj format for VS 2008 were compatible with 2005). Jory sets up the release version to be statically-linked, so the only motivation for .MSI packaging is the ease of service installation.