Re: Tracking child processes

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.

Comment on Re: Tracking child processes

Replies are listed 'Best First'.
Re^2: Tracking child processes by Zubinix (Acolyte) on Sep 30, 2006 at 13:07 UTC
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]
Re^3: Tracking child processes by eyepopslikeamosquito (Archbishop) on Sep 30, 2006 at 14:44 UTC
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]