Maybe I was too vague in my initial posting. Let's say you create the file: /tmp/dataCruncher.exe.lock.1928 in the script that creates the lock file. You "parent" script can then look into /tmp for files matching the pattern "dataCruncher\.exe\.lock.([0-9]+)" (or ""dataCruncher.exe.lock followed by a period and one or more numbers.")(or whatever type of regex you plan on using)

in the above PCRE regex, the language/utility/whatever will create a backreference for the number portion of the pattern under "1."

proof of concept in Perl:

Code:

#!/usr/bin/perl -w

our @files = </tmp/dataCruncher.exe.lock*>;
our @pids = ();

foreach $file (@files) {
           $file =~ /dataCruncher\.exe\.lock\.([0-9]+)/;
           push ( @pids, $1 );
}

@pids ends up being an array of PIDs retrieved out of lockfile filenames in such a way.

Hope that makes what I'm saying seem a little clearer.

Random numbers aren't random. Port numbers aren't guarantees. There is ambiguity in real world applications. Since, as you admit, identifying information is destroyed before you have the chance to save it, you're forced to depend on heuristics, which are fuzzy by their nature, but a best-guess that's known as being a best-guess is better than no idea at all.

Criteria you can examine the process tree for: username, time, command, parent(1), etc. All of which make it less likely that you've caught more than one process in the fray. You also haven't mentioned how you're creating the lockfile. It would seem a process that can know when the children die off can also do the above file naming.

Well, I think I can maybe help a little more if I understand more about how you're creating the lockfile.