Put a group of commands into background and obtain the pids for each of them.

[Hongyi Zhao]

Hi all,

Suppose I've a group of commands which must be executed sequentially, but
each of them is time-consuming. So I want to put these commands in a
group and then put them into background.

At the meanwhile, I must obtain the pids for each of them in order to
facilitate the testing on them with the `kill -0 $PID'.

Basically, the requirements are as follows:

1- Group some commands as a unit and let them executed sequentially;
2- Put these commands into background so that they are not blocking the
subsequent commands in the same script for running.
3- Obtain the PID for each of these commands and store them in an array
for subsequent use.

Is this possiable?

Regards
--
.: Hongyi Zhao [ hongyi.zhao AT gmail.com ] Free as in Freedom :.

[Hongyi Zhao]

On Thu, 09 Apr 2015 02:52:41 +0000, Hongyi Zhao wrote:

> Basically, the requirements are as follows:
>
> 1- Group some commands as a unit and let them executed sequentially; 2-
> Put these commands into background so that they are not blocking the
> subsequent commands in the same script for running.
> 3- Obtain the PID for each of these commands and store them in an array
> for subsequent use.
>
> Is this possiable?

I've tried the following codes:

werner@debian:~$ { dig youtube.com; ping 127.0.0.1; } > /dev/null &
[1] 4930
werner@debian:~$ pgrep dig
werner@debian:~$ pgrep ping
4935

But I cann't figure out the relationship between the PID 4930 and 4935.

Even I kille the process for PID 4930, the ping with PID 4935 is still
alive:

werner@debian:~$ kill 4930
werner@debian:~$ pgrep ping
4935
[1]+ Terminated { dig youtube.com; ping 127.0.0.1; } > /dev/
null
werner@debian:~$ pgrep ping
4935

Any hints?

[Barry Margolin]

In article <mg4ptk$l53$2...@aspen.stu.neva.ru>,

Hongyi Zhao <hongy...@gmail.com> wrote:

> On Thu, 09 Apr 2015 02:52:41 +0000, Hongyi Zhao wrote:
>
> > Basically, the requirements are as follows:
> >
> > 1- Group some commands as a unit and let them executed sequentially; 2-
> > Put these commands into background so that they are not blocking the
> > subsequent commands in the same script for running.
> > 3- Obtain the PID for each of these commands and store them in an array
> > for subsequent use.
> >
> > Is this possiable?
>
> I've tried the following codes:
>
> werner@debian:~$ { dig youtube.com; ping 127.0.0.1; } > /dev/null &
> [1] 4930
> werner@debian:~$ pgrep dig
> werner@debian:~$ pgrep ping
> 4935
>
> But I cann't figure out the relationship between the PID 4930 and 4935.

4930 is the process group leader, 4935 is a child of that process.

>
> Even I kille the process for PID 4930, the ping with PID 4935 is still
> alive:
>
> werner@debian:~$ kill 4930
> werner@debian:~$ pgrep ping
> 4935
> [1]+ Terminated { dig youtube.com; ping 127.0.0.1; } > /dev/
> null
> werner@debian:~$ pgrep ping
> 4935
>
> Any hints?

Kill the whole process group, by negating the process group ID:

kill -KILL -4930

--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

[Hongyi Zhao]

On Thu, 09 Apr 2015 00:00:32 -0400, Barry Margolin wrote:

[snip]

> 4930 is the process group leader, 4935 is a child of that process.

Then, as I've posted in the this thread, how can I obtain the pids for
all of these children processes?

>
>
>> Even I kille the process for PID 4930, the ping with PID 4935 is still
>> alive:
>>
>> werner@debian:~$ kill 4930 werner@debian:~$ pgrep ping 4935 [1]+
>> Terminated { dig youtube.com; ping 127.0.0.1; } > /dev/
>> null werner@debian:~$ pgrep ping 4935
>>
>> Any hints?
>
> Kill the whole process group, by negating the process group ID:
>
> kill -KILL -4930

Thanks for your hints.

[Kaz Kylheku]

On 2015-04-09, Hongyi Zhao <hongy...@gmail.com> wrote:
> On Thu, 09 Apr 2015 00:00:32 -0400, Barry Margolin wrote:
>
> [snip]
>
>> 4930 is the process group leader, 4935 is a child of that process.
>
> Then, as I've posted in the this thread, how can I obtain the pids for
> all of these children processes?

There isn't any systel-level API for doing that in POSIX. You have to
scrape that information out of the output of "ps", or else look toward
system-specific methods like the /proc filesystem on Linux.

POSIX groups and job control exists in order to support some features of the
tty + shell environment.

The shell command interpreter parses command pipelines and generates processes
which are lumped together in a group. The shell knows the process ID's of all
these processes because it created them. It knows which group is the foreground
process group at any time, and so on. Internally, it has data structures to
keep track of this.

The shell language could have language features to allow scripts to get at this
information: a command pipeline or group could be exposed as some kind of
object, which could be traversed to obtain its components, including the ID's
of the processes it contains. This just doesn't exist, though.

There is the "jobs" command which only lists the active command pipes, along
with the pid of their process group leader. You cannot get to the individual pids
of the pipeline components.

"jobs" works by traversing the internal data structures of the shell that it
uses for keeping track of jobs. Similar commands could be provided to inspect
more deeply into the jobs, but aren't.

[Hongyi Zhao]

On Thu, 09 Apr 2015 05:27:53 +0000, Kaz Kylheku wrote:

[snip]

>> Then, as I've posted in the this thread, how can I obtain the pids for
>> all of these children processes?
>
> There isn't any systel-level API for doing that in POSIX. You have to
> scrape that information out of the output of "ps", or else look toward
> system-specific methods like the /proc filesystem on Linux.
>
> POSIX groups and job control exists in order to support some features of
> the tty + shell environment.
>
> The shell command interpreter parses command pipelines and generates
> processes which are lumped together in a group. The shell knows the
> process ID's of all these processes because it created them. It knows
> which group is the foreground process group at any time, and so on.
> Internally, it has data structures to keep track of this.
>
> The shell language could have language features to allow scripts to get
> at this information: a command pipeline or group could be exposed as
> some kind of object, which could be traversed to obtain its components,
> including the ID's of the processes it contains. This just doesn't
> exist, though.
>
> There is the "jobs" command which only lists the active command pipes,
> along with the pid of their process group leader. You cannot get to the
> individual pids of the pipeline components.
>
> "jobs" works by traversing the internal data structures of the shell
> that it uses for keeping track of jobs. Similar commands could be
> provided to inspect more deeply into the jobs, but aren't.

Thanks for your explanations.