I want to know how I can create in PHP or Perl, preferably PHP, a script to count the number of system processes that are using a specific executable.

I want to have a script to check the total number of "CMD.EXE" processes running, and then have it notify me when there are more than perhaps five. The notification portion I already have, but how to actually count the number of individual processes spawned running CMD.EXE is what I need.

... and there are the keys to almost anything in the Windows OS, either tapping directly into the Windows API (as the Win32::Process::Info module does on NT) or the WMI as James has done in his php snipit and Win32::Process::Info will as one of it's backups if it cannot directly talk to the API.

I did not write this, but I did adapt it for my purposes. The issue is that while I must run PHP in Apache Module, I cannot use F/CGI for what I am doing.

So occasionally some of the modules that Image Magick calls crash, they are not thread safe. IM creator claims that IM is itself threadsafe but that he cannot say the same about modules that IM uses.

I was using a chron job to run a PHP script via CLI, but that was not reliable. I have not had the time to investigate. I am trying this VBS that I adapted, here is the script I am using with a chron running every 120 seconds:

I found that if the CMD.exe count is higher than four or five typically this is a solid indication that there was a crash. This is far from scientific, it is a terrible solution to a problem that just mystifies me. Why can't a crashed thread internal to Apache be detected and dealt with? I understand that it is PHP calling a script that calls an executable that then calls other DLL's, but ultimately the crash must be detectable by the server, isn't it?

But in this case I think PHP should be doing that since it's the one spawning off a child process ... I think. mod_fcgid AFAIK handles the processes it spawns off itself.

However, I found this to be an interesting comment on the dev list. It's covers a few thing but a process management module is what is being talked about in it as well. Heck interesting, it actually sounds real good to me .. all of it .. plugins included.

The script I was using via CLI and a chron job would work most of the time, but not all of the time. The advantage of this VBS solution is it does not require PHP or Apache, it is purely an OS scheduled task running a native language that the OS understands (Visual Basic Script).

When a thread crashes it will have two programs open. I make an EXEC call to an Image Magick executable, such as CONVERT.EXE and that opens a CMD.EXE window, thus I count the CMD's because Image Magick has other programs like MOGRIFY.EXE and others. If convert calls a library that is not thread safe and crashes it brings the entire server down.

This is insane!

The work around is either:

A) Use Linux -> learn Linux and how to administrate a server and all the components such as Apache, Perl, PHP, MySQL, and so on...

- or -

B) Use F/CGI -> lose the ability to run the module and thus each vhost uses same INI file. If I want I could run some in cgi and some as module - that is that really the right way to go?

If an EXEC call in PHP results in a crash, calling subsequent EXEC functions will not necessarily execute at all - thus there is no assurance that the process will work.

This has been a problem for Windows and Apache with any type of SAPI interface since the beginning. Non-Thread safe programs bringing down the server.

As I said, this is nuts, why has this never been addressed? There are many WAMP servers out there but I still feel that Apache shoots itself in the foot wanting to be for *nix but lets Windows play with it a little bit.

B) Use F/CGI -> lose the ability to run the module and thus each vhost uses same INI file. If I want I could run some in cgi and some as module - that is that really the right way to go?

You can also in FCGID define different php.ini files or use php_admin_value in each vhost to define the differences. What is the advantage of the module? OK cgi is slow and some session things do not work, but with fcgid it is different. I haven't found a software from my script that don't run.

Brian wrote:

If an EXEC call in PHP results in a crash, calling subsequent EXEC functions will not necessarily execute at all - thus there is no assurance that the process will work.

Did you try the @ operator? OK it is ugly, but sometimes it prevents aborting of the script.

I should not HAVE to re-design my programs to do things differently. I should not HAVE to design around what seems to be a weakness or flaw - though I do have to if I want to avoid any risk of this issue coming up.

I had built a comprehensive platform for file management, integrating mail, stripping attachments, online image manipulation, and build web pages.

I integrated a a number of open source scripts into my own framework and programming.

I am using PHP, Perl, and a lot of command line calls.

In order for me to make the entire system work under a different model would be an immense undertaking.

Likewise my services did not grow over night, so there was a breaking point where the services I was adding, the integration of services and conveniences would grow at a rate that just did not make starting over very attractive.

Redesign - testing, debugging, more testing, more debugging...

When the point I am driving at is that Apache should not be brought down because of a JPG conversion module called by IM which was called by PHP which was called from within Apache crashes. I guess to some degree I am venting, for that I am sorry.

But to a larger degree I am looking at a bandaid solution to a problem that consumes far less time and effort and hopefully produces satisfactory "enough" results.

It seems that if Apache could not be brought to it's knees by a subsequent call to a non-thread safe module, then that would be the best solution.