You're probably gonna have to be more specific about your architecture and code and problems before anyone can help you.
I don't know what timescales you're working on, but running an occasional ps shouldn't be that much of a burden. Have you tried?
Check this out for a start: Proc::ProcessTable
| [reply] |
Thanks for the link to Proc::ProcessTable. Its hard to be specific because I have to tackle this problem generally. Don't worry about timescale it not important. The point of the post is to find out methodologies people use to track process creation and do the tidy up at the end. For example, I kick off a script which launches multiple scripts on remote machines. These scripts in turn have many child processes which sometimes die before cleaning up thus leaving orphan processes lying around which might be holding resources such as file handles. This interferes with subsequent automation runs.
So, what methods are there in perl for real time process tracing? Such a method would allow clean up of child processes without interfering with other processes on the machine (regardless of user). Has anyone tackled a problem like this before?
| [reply] |
How about one of the Proc modules like Proc::Reliable?
There are several in the Proc namespace you could try.
| [reply] |
I've written a similar system, but for Unix boxes only.
What I did was to make the main Unix build script
a process group leader and record this process group
locally (i.e. on the "build driver" machine) in a
"build state" file when starting the build script
remotely from the build driver machine.
With that done, to kill the build on any Unix box from
the build driver machine, I simply look up the process
group of the build script from the local "build state"
file and issue a remote command to kill that process
group (i.e. kill -process-group-id), which will kill
all build processes started from the main build script.
As a precaution, after looking up the process group id,
I do a remote "ps" command to list the processes belonging
to that process group and prompt for confirmation before
killing.
| [reply] |
This is similar to what I want. I think MS Windows has a similar concept to unix's group leader. Was your system written in perl?
| [reply] |
Yes, it was a work system written in Perl. I don't have the code available to me right now though because I'm at home.
Early versions of Windows did not have a similar concept to Unix's process groups ... and so applications such as Visual Studio rolled their own complex custom schemes to achieve a similar effect. This was remedied with the introduction of Jobs in Windows 2000. The Win32::Job module (comes with ActivePerl, needs Windows 2000 and above) should be a suitable replacement for Unix process groups.
| [reply] |
My question is how to track child processes that run remotely on these machines so that if something goes wrong (or hangs indefinitely) the errant process can be identified and terminated?Thats a pretty broad question, but the first model that pops into my head, is one where for every remote process you launch, you launch a companion watcher script, which watches the process and reports back via sockets. Then at your control machine, you collect the progress reports, and analyze them. You will need an event loop system for your collection script( like POE, Tk, Gtk2, Glib ), so you can simultaneously collect socket data and analyze them. The companion watcher script would sleep most of the time, waking up periodically checking the running time of it's assigned pid, log entries, etc, and reporting them in over the socket.
| [reply] |