Finding process id of subsequent process

hi all,

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

For eg:

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 :

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. :slight_smile: :b:

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 :slight_smile:

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:

#!/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.

thmnetwork - many thanks for the continued reply

this is how it goes,
envVarSetter dataCrunch.exe

I can only capture the pid of envVarSetter and not the pid of dataCrunch.exe as the latter would be spawned as the child of envVarSetter and not as the child of main spawner / controller

So collecting pid here
1) is not useful for checking the status of process whether its running or not
2) or for creating a lock files because lock file would be created before the actual process is spawned.

For ex:

This is how the process is spawned in sequence.

echo $running_no > $lock_file ; envVarSetter dataCrunch.exe; rm $lock_file

Here, how can I fit the usage of pids here.
If I have not explained properly or improperly please do let me know

thanks :slight_smile:

I'm going to add more to this post later, but one idea would be to spawn another process in your serialized command there that does nothing but wait a second and then quickly looks for the envVarSetter located underneath your parent script, and take its pid out that way. Or you may find your solution by leveraging process grouping (I'm assuming from "init" that this is unix anyways.)

UPDATE

Ok, experimenting with perl child processes a bit on Aix 5.2 it looks like both tty and nice values are inherited by children even after the parent gets cruelly kill -9'd.

This opens the door for possible additional differentiation if you launch envVarSeter via the "nice" command. in additon to time, command, and username(if variable) criteria you can add the tty (if variable) and a randomly generated nice value. You could even store the last three or four generated nice values. That requires a collision to be between dataCrunchers launched with three or four others in the same second, under the same username, on the same tty, and with the same randomly generated nice value. I think that sufficiently would shrink the collision domain for us unless you have one hellacious load level. After you find the PID by the criteria after the fact you can re-adjust the nice's to production levels.

The main obstacle I can see is if envVarSetter clobbers the nice value. You'll probably want to find a way to run the command from the command line in a non-destructive way. Not sure what dataCruncher.exe or envVarSetter are so you're probably on your own as far as whether "coding the nice level" will work. If you could find something within process groups that works, that would probably be more ideal for you.

probably process group is a nice idea. I will try evaluating in that domain.

Regarding nice value, tty inheritance - there is a potential problem if I rely on them.

I am trying to frame a generic script and the multiple chunks that are being executed, needlessly might turn out to a be a daemon therefore

1) detaching itself from a tty
2) altering the nice value
3) can switch between multiple process groups

the above is not something frequent but the generic capability of the script will be affected.

Am really wondering, is n't there an easy way to track child process by the parent - condition being parent is short lived and child being inherited by init.

Thanks again :slight_smile: