I certainly know there is a parent process id in the output of ps.
However, in many cases, that info is less than useless (when the
parent process is gone, for instance).

What I need is some code I can put into ksh script abc so that it can
output the name of the process which started it.

Are there either existing tools, or techniques, by which this
information could be derived?

I'm currently in an environment where Solaris 8/9/10 are all in use,
and the script is written in ksh88i

Thanks!

Larry W. Virden wrote:
> I certainly know there is a parent process id in the output of ps.
> However, in many cases, that info is less than useless (when the
> parent process is gone, for instance).
>
> What I need is some code I can put into ksh script abc so that it can
> output the name of the process which started it.
>
> Are there either existing tools, or techniques, by which this
> information could be derived?

How about

ps -p $PPID


Janis

>
> I'm currently in an environment where Solaris 8/9/10 are all in use,
> and the script is written in ksh88i
>
> Thanks!
>

Janis Papanagnou wrote:
> Larry W. Virden wrote:
>
>> I certainly know there is a parent process id in the output of ps.
>> However, in many cases, that info is less than useless (when the
>> parent process is gone, for instance).
>>
>> What I need is some code I can put into ksh script abc so that it can
>> output the name of the process which started it.
>>
>> Are there either existing tools, or techniques, by which this
>> information could be derived?
>
>
> How about
>
> ps -p $PPID

Let me add, to get the name of the process and suppress the header
you can use (on Linux; I can't tell for Solaris' ps options)

ps h -p $PPID -o "%c"


Janis

>>
>> I'm currently in an environment where Solaris 8/9/10 are all in use,
>> and the script is written in ksh88i
>>
>> Thanks!
>>

Janis Papanagnou wrote:
> Larry W. Virden wrote:
>> I certainly know there is a parent process id in the output of ps.
>> However, in many cases, that info is less than useless (when the
>> parent process is gone, for instance).
>>
>> What I need is some code I can put into ksh script abc so that it can
>> output the name of the process which started it.
>>
>> Are there either existing tools, or techniques, by which this
>> information could be derived?
>
> How about
>
> ps -p $PPID
>
>

or

/bin/ps -o comm -p $PPID

The OS does not keep track about terminated processes.
But at the beginning of your script there is a good chance that
the parent process is yet alive.


--
Michael Tosch @ hp : com

On 2007-05-23, Larry W. Virden <lvirden@gmail.com> wrote:

> Are there either existing tools, or techniques, by which this
> information could be derived?

You can certainly obtain the PID of the parent process using $PPID in
your ksh script, however obtaining a name from a process that has gone
away could be difficult. I gather the parent process doesn't hang around
waiting for its child to finish? Perhaps the parent could pass a name
as an argument to the child script?


--
Andre.

On May 23, 8:23 pm, Andre <nnte...@africa.purplecow.org> wrote:
> On 2007-05-23, Larry W. Virden <lvir...@gmail.com> wrote:
>
> > Are there either existing tools, or techniques, by which this
> > information could be derived?
>
> You can certainly obtain the PID of the parent process using $PPID in
> your ksh script, however obtaining a name from a process that has gone
> away could be difficult. I gather the parent process doesn't hang around
> waiting for its child to finish? Perhaps the parent could pass a name
> as an argument to the child script?

My problem is locating the parent process - can't change it until I
find it :smile:.

What I am seeing in ps is hundreds of occurences of a particular
process, by hundreds of people. But I can't find any thing that runs
that process (and people don't run this by hand). In every case, ps
lists the PPID as being 1... so whatever is starting this is going
away.

So I need to figure out what is calling the shell command. I've added
an echo of $PPID at the beginning of the script - we'll see. But it
would be nice to have some additional info. We aren't running process
accounting - that might provide me additional info, but isn't an
option as far as I am aware.

2007-05-23, 21:52(+02), Michael Tosch:
> Janis Papanagnou wrote:
>> Larry W. Virden wrote:
>>> I certainly know there is a parent process id in the output of ps.
>>> However, in many cases, that info is less than useless (when the
>>> parent process is gone, for instance).
>>>
>>> What I need is some code I can put into ksh script abc so that it can
>>> output the name of the process which started it.
>>>
>>> Are there either existing tools, or techniques, by which this
>>> information could be derived?
>>
>> How about
>>
>> ps -p $PPID
>>
>>
>
> or
>
> /bin/ps -o comm -p $PPID
>
> The OS does not keep track about terminated processes.
> But at the beginning of your script there is a good chance that
> the parent process is yet alive.
[...]

Note that it is not clear what $PPID contains, at least
according to POSIX. It says:

PPID
Set by the shell to the decimal process ID of the
process that invoked this shell. In a subshell (see
Shell Execution Environment), PPID shall be set to the
same value as that of the parent of the current shell.
For example, echo $ PPID and ( echo $ PPID ) would
produce the same value. This volume of IEEE Std
1003.1-2001 specifies the effects of the variable only
for systems supporting the User Portability Utilities
option.

That doesn't make sense to me. How would a process invoke
another process? The most sensible way would be via an exec*()
system call, in which case $$ would be the same as $PPID.

The definition for "invoke" is not very ful:

To perform command search and execution actions, except
that searching for shell functions and special built-in
utilities is suppressed; see also Execute.

Practically, $PPID contains the value of getppid() at the time
of the shell's initialisation, so in cases where the parent is
gone by the time the shell does the getppid(), $PPID will likely
be 1, even though I don't think we can say that init invoked
that shell.

ps -p "$$" -o ppid=

will return the parent process id of the shell at the time this
command is run (which may be different from $PPID if $PPID is
gone by now).

~$ (sh -c 'ls -d /proc/$PPID' &); sleep 1
/proc/1
~$ (sh -c 'sleep 2; ls -d /proc/$PPID' & sleep 1); sleep 2
ls: /proc/8121: No such file or directory

--
Stéphane

Larry W. Virden wrote:
> I certainly know there is a parent process id in the output of ps.
> However, in many cases, that info is less than useless (when the
> parent process is gone, for instance).
>
> What I need is some code I can put into ksh script abc so that it can
> output the name of the process which started it.

ptree $$
should do the job. You even see the complete process history above your
script.

>
> Are there either existing tools, or techniques, by which this
> information could be derived?
>
> I'm currently in an environment where Solaris 8/9/10 are all in use,
> and the script is written in ksh88i

Perhaps dtrace on Solaris 10 would be an alternative.

Juergen

--
Juergen Gross Principal Developer
IP SW OS6 Telephone: +49 (0) 89 636 47950
Fujitsu Siemens Computers e-mail: juergen.gross@fujitsu-siemens.com
Otto-Hahn-Ring 6 Internet: www.fujitsu-siemens.com
D-81739 Muenchen Company details: www.fujitsu-siemens.com/imprint.html

On 24 Mai, 13:55, "Larry W. Virden" <lvir...@gmail.com> wrote:
> On May 23, 8:23 pm, Andre <nnte...@africa.purplecow.org> wrote:
>
> > On 2007-05-23, Larry W. Virden <lvir...@gmail.com> wrote:
>
> > > Are there either existing tools, or techniques, by which this
> > > information could be derived?
>
> > You can certainly obtain the PID of the parent process using $PPID in
> > your ksh script, however obtaining a name from a process that has gone
> > away could be difficult. I gather the parent process doesn't hang around
> > waiting for its child to finish? Perhaps the parent could pass a name
> > as an argument to the child script?
>
> My problem is locating the parent process - can't change it until I
> find it :smile:.

Change what?

> What I am seeing in ps is hundreds of occurences of a particular
> process, by hundreds of people.

No, what you see is rather a hundred processes of a particular
program. You can restrict the number of processes displayed by ps
options. A process (with the exception of the init process) has
always a single direct "predecessor", one parent.

> But I can't find any thing that runs
> that process (and people don't run this by hand). In every case, ps
> lists the PPID as being 1... so whatever is starting this is going
> away.

The parent has PID 1 if it is either started by the init process or if
the real parent process has disowned its child; the latter can be the
standard behaviour for demon processes, or by calling your process abc
in a special way like ( abc & ) , or by manually disown the process
(if your shell allows that), just to name a few common examples. I
don't think that it's generally possible in such cases to obtain the
PPID of the caller.

> So I need to figure out what is calling the shell command. I've added
> an echo of $PPID at the beginning of the script - we'll see. But it
> would be nice to have some additional info. We aren't running process
> accounting - that might provide me additional info, but isn't an
> option as far as I am aware.

What "additional info" do you need? You can get everything about the
process that the ps command on your machine will give you (see man
page of your ps variant). But only if the process had been started,
umm.. - "conventionally".

Janis

Stephane CHAZELAS wrote:

> Note that it is not clear what $PPID contains, at least
> according to POSIX. It says:
>
> PPID
> Set by the shell to the decimal process ID of the
> process that invoked this shell.
[snip]
>
> That doesn't make sense to me. How would a process invoke
> another process? The most sensible way would be via an exec*()
> system call, in which case $$ would be the same as $PPID.

Good catch!

It would be appreciated if you could submit a defect report to
the Austin Group so that this can be corrected.

--
Geoff Clare <netnews@gclare.org.uk>

2007-05-24, 06:02(-07), Janis:
[...]
> The parent has PID 1 if it is either started by the init process or if
> the real parent process has disowned its child;

Well, no, if the parent has terminated, that's it.

> the latter can be the
> standard behaviour for demon processes, or by calling your process abc
> in a special way like ( abc & )

In that case, the parent (the subshell) terminates just after
having spawned the process that exec()s abc.

> or by manually disown the process
> (if your shell allows that), just to name a few common examples. I
> don't think that it's generally possible in such cases to obtain the
> PPID of the caller.

No, if you're refering to the "disown" command in shells like
zsh or bash, it's only for job control, and that only removes it
from its *internal* job table (so that for instance it doesn't
then the job a SIGHUP signal when it exits).

>> So I need to figure out what is calling the shell command. I've added
>> an echo of $PPID at the beginning of the script - we'll see. But it
>> would be nice to have some additional info. We aren't running process
>> accounting - that might provide me additional info, but isn't an
>> option as far as I am aware.
>
> What "additional info" do you need? You can get everything about the
> process that the ps command on your machine will give you (see man
> page of your ps variant). But only if the process had been started,
> umm.. - "conventionally".
[....]

Basically, what I understand is that there is some process that
does something like:

while true; do
(some-script &)
sleep 1
done

so that ps shows many instances of some-script with ppid 1. The
question is how to find out which process is doing that loop?

looking at which files the instances of some-script have open
or what is their controlling terminal if any may to narrow
down the list of suspects.

--
Stéphane

In article <slrnf5b58c.7lg.stephane.chazelas@spam.is.invalid> ,
Stephane CHAZELAS <this.address@is.invalid> wrote:
....
>from its *internal* job table (so that for instance it doesn't
>then the job a SIGHUP signal when it exits).

Huh?

2007-05-24, 15:48(+00), Kenny McCormack:
> In article <slrnf5b58c.7lg.stephane.chazelas@spam.is.invalid> ,
> Stephane CHAZELAS <this.address@is.invalid> wrote:
> ...
>>from its *internal* job table (so that for instance it doesn't
>>then the job a SIGHUP signal when it exits).
>
> Huh?

~$ strace -e kill zsh
kill(10728, SIG_0) = 0
--- SIGCHLD (Child exited) @ 0 (0) ---
kill(10728, SIG_0) = -1 ESRCH (No such process)
--- SIGCHLD (Child exited) @ 0 (0) ---
kill(-10729, SIG_0) = -1 ESRCH (No such process)
--- SIGCHLD (Child exited) @ 0 (0) ---
kill(-10730, SIG_0) = -1 ESRCH (No such process)
~$ sleep 10 &
[1] 10731
1~$ exit
zsh: you have running jobs.
1~$ exit
kill(-10731, SIGHUP) = 0
zsh: warning: 1 jobs SIGHUPed
Process 10727 detached

(controlled by the "hup" option)

most shs will send its jobs a SIGHUP if it's itself killed by a
SIGHUP (to avoid orphans).

--
Stéphane

Larry W. Virden wrote:
> I certainly know there is a parent process id in the output of ps.
> However, in many cases, that info is less than useless (when the
> parent process is gone, for instance).
>
> What I need is some code I can put into ksh script abc so that it can
> output the name of the process which started it.
>
> Are there either existing tools, or techniques, by which this
> information could be derived?
>
> I'm currently in an environment where Solaris 8/9/10 are all in use,
> and the script is written in ksh88i

On Solaris, try ptree (and its relatives, collectively known as the
p-tools). On other systems you can download 'pstree', a free program.

Once you have the pid of a process you can use 'pargs' (another p-tool)
to get its command line.

HT

2007-05-24, 22:45(-04), Henry Townsend:
> Larry W. Virden wrote:
>> I certainly know there is a parent process id in the output of ps.
>> However, in many cases, that info is less than useless (when the
>> parent process is gone, for instance).
>>
>> What I need is some code I can put into ksh script abc so that it can
>> output the name of the process which started it.
>>
>> Are there either existing tools, or techniques, by which this
>> information could be derived?
>>
>> I'm currently in an environment where Solaris 8/9/10 are all in use,
>> and the script is written in ksh88i
>
> On Solaris, try ptree (and its relatives, collectively known as the
> p-tools). On other systems you can download 'pstree', a free program.
[...]

some systems (at least Linux and HPUX) have the -H option to ps
to get a tree representation (you need to have "UNIX95=" in the
environment passed to ps on HPUX).

But neither that nor ptree will here, it will only show a
bunch of leaves directly connected to the trunc (init).

--
Stéphane

On 2007-05-24, Stephane CHAZELAS <this.address@is.invalid> wrote:
>
> Note that it is not clear what $PPID contains, at least
> according to POSIX. It says:
>
> PPID
> Set by the shell to the decimal process ID of the
> process that invoked this shell. In a subshell (see
> Shell Execution Environment), PPID shall be set to the
> same value as that of the parent of the current shell.
> For example, echo $ PPID and ( echo $ PPID ) would
> produce the same value. This volume of IEEE Std
> 1003.1-2001 specifies the effects of the variable only
> for systems supporting the User Portability Utilities
> option.
>
> That doesn't make sense to me. How would a process invoke
> another process? The most sensible way would be via an exec*()
> system call, in which case $$ would be the same as $PPID.

Well, I'll begin by putting this awkward use of the word 'invoke'
to one side for a moment and considering the matter from first
principles.

Under Unix or indeed POSIX, processes are _not_ created by exec().
That job is done by fork(). The exec...() functions (usually
execve() under the hood although I doubt POSIX mandates this)
_modify_ an _existing_ process. Replacing the entire process image
is an extensive modification but it is a modification nevertheless.
Therefore if we talk of a process creating a process we can only
be referring to fork() and not exec...().

> The definition for "invoke" is not very ful:
>
> To perform command search and execution actions, except
> that searching for shell functions and special built-in
> utilities is suppressed; see also Execute.

.... and the definition of Execute is not more enlightening.
Indeed, it is written in pretty much the same terms.

However, if we go back to our first principles, if we talk about
a process invoking _another_ process, we _must_ be talking about
fork(). If you read between the lines in the invoke definition,
it appears to be talking about the whole sequence of tasks in
spawning a child process, beginning with locating the executable
and fianlly exec'ing it. The fork in the middle is not mentioned.
Presumably it is implied but I'd agree clarification would be
ful. Regardless, the intent seems pretty clear to me.

--
Andrew Smallshaw
andrews@sdf.lonestar.org
[who has just found a bug in fmt with paragraphs that start with a '.'...]