Topic: Script to count number of specific processes

[Brian]

Potentially this is too much to ask, but I will give it a shot.

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.

Is this even possible to determine via PHP, or Perl?

Thanks.

[paranid]

I do not know how to do this the secure/better way, because you need to have enabled shell_exec() function!

PHP:

[glsmith]

This is almost verbatim out of the ActivePerl docs
Win32::Process::Info

[Brian]

Thank you both for your reply, they were quite helpful.

[James Blond]

here a working php script like the great perl script from Gregg.

[glsmith]

... 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.

[Brian]

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:

[glsmith]

*shrugs*

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.

http://marc.info/?l=apache-httpd-dev&m=125746748513752&w=2

[James Blond]

Back to your problem

[code]
<?php
$wmi = new COM('winmgmts://');
$processes = $wmi->ExecQuery("SELECT * FROM Win32_Process WHERE Name = 'CMD.EXE'");
$instance = 0;
foreach($processes as $process){
$instances[$instance] = $process->ProcessId . "\r\n";
}

$result = count($instances);
if($result >= 4){
foreach($instances as $instance){
exec("Taskkill /F /PID $instance >nul 2>&1");
}
}
?>

That should kill the cmd.exe's

I wonder which part of your program causes all that cmd.exe's
You call imagemagick from the command line with exec?

[Brian]

PHP would work except that I found it just doesn't work reliably.

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.

Frustrating

[James Blond]

[Brian]

I thought that the "@" operator essentially just turned of error reporting / checking, such as during a SQL connection, file open operation and so on.

F/CGI does not work with some things I do, I have tested it.

Speed is very important, my server is very heavy in image manipulation - heavy CPU and a plethora of session activity, connections to SQL, and constant updating info in SQL and session...

So a server that breathes easy is very important.

[James Blond]

Did you ever think of putting the session data into the DB to speed up your applications?

[Brian]

Okay you are hitting two key points that I want to address.

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.

Does that make sense?