UNIX for Advanced & Expert Users

hi all,

I am trying to find the process id of the subsequent process created via fork and exec calls in perl.

For eg:

Code:

envVarSetter dataCruncher.exe < input.txt > output.txt

When I fork and exec the above command,
it returns only the pid of envVarSetter and I don't know how to find the pid of dataCruncher.exe

Option of pgrep, grepping by process name don't seem to suit my case and it will only involve additional processing. Also, multiple different parameters are passed which when grepped will return different values, so that's not a nice option

In short, is there a way to find out the pid of subsequent process executed in one command?

What gives the following :

Code:

pgrep -P $$

option of pgrep :
-P ppid,... Only match processes whose parent process ID is listed.

as $$ returns the ID of the current program, the command above should return the ID's of subsequent processes.

Thanks for the reply.
But that is not the case really.

As I have told that, 2 processes are executed in sequence,
where the first one completes [ envVarSetter ] in no time which means the second process [ dataCruncher.exe ] would be left orphaned and init adopts that, therefore PPID of the second process is 1 and no more the PID that created it.

This makes the problem hard to find out the PID of the subsequent process.
Since they almost execute one after another, I have noticed most of the times that if PID of first process is 'x' and PID of second process is 'x+1' but that is a crude assumption and I can't go with that.

In a very busy system, my script would be thrashed left and right ...

Am just searching for a better way to do that.

Thanks for your reply again.

I managed to get this working with a lock file concept in place.

To create a file - presence of which will indicate that the process is created and after the process is done, the next command in sequence is to delete the file. This indirectly means, if there is no file then processing is done.

With this approach its perfectly working - no issues for now

But to say frankly, I hate this approach like anything
it is not robust
not fool proof
can be hacked
no control of child created via the parent

Am still looking for some help from experts here to get the actual pid that am interested.

Unless you expect the first script to finish within a second or two, frans's solution is fine. Also, if you added a lock file that gets deleted when the process ends, can't you use the same script that creates the lock file to create it with the pid in the lock file's name? Alternative concepts could be to have envVarSetter write the pid of the child and any other useful info to its parent process's read pipe.

Alternatively, you could look through children of init for processes of that name that began a within a second or two of the script's initial running.

etc, etc. There are a lot of possibilities.

That needed not be the case, and the solution that am trying for is some generic solution

A lock file with pid in it isn't really making any difference here, just a running number to keep track of the active child count should do and that is what i had done for now

Again an important point is being missed out here,
say at t1 the main script spawns a process p1 and is adopted by init at the same time t1, another script with the same name can be spawned and become the child of the init

In a busy node, all these considerations should be dealt well, else there would be confusion as to who is the parent of whom

-- many thanks for the suggestions

---------- Post updated 11-05-09 at 11:27 AM ---------- Previous update was 11-04-09 at 11:34 PM ----------

Now I have an improved way to prevent the hack of spoofing child creation instance by adding new files at least to an extent.

Instead of writing the active child number spawned, write a random number to the file and maintain that in an internal hash. When checking for the existence of file as a synonym that is indicating whether a process is running or not, search for the entry in the file and compare it against the internal hash that is built with this values. With this, spoof of child creating by just touching files can be avoided.

I don't want to write the pid because effectively we are writing the PPID and not PID which should be avoided.

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.