|
Home > Archive > Unix Shell > May 2007 > what alternatives does a shell command have in determining its parent?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
what alternatives does a shell command have in determining its parent?
|
|
| Larry W. Virden 2007-05-23, 1:18 pm |
| 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!
| |
|
| 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.
| |
| Larry W. Virden 2007-05-24, 7:20 am |
| On May 23, 8:23 pm, Andre <nnte...@africa.purplecow.org> wrote:
> On 2007-05-23, Larry W. Virden <lvir...@gmail.com> wrote:
>
>
> 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.
| |
|
| On 24 Mai, 13:55, "Larry W. Virden" <lvir...@gmail.com> wrote:
> On May 23, 8:23 pm, Andre <nnte...@africa.purplecow.org> wrote:
>
>
>
>
> 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 2007-05-24, 1:18 pm |
| 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).
>
> 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 help to narrow
down the list of suspects.
--
Stéphane
| |
| Kenny McCormack 2007-05-24, 1:18 pm |
| 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?
| |
| Stephane CHAZELAS 2007-05-24, 1:18 pm |
| 2007-05-24, 15:48(+00), Kenny McCormack:
> In article <slrnf5b58c.7lg.stephane.chazelas@spam.is.invalid>,
> Stephane CHAZELAS <this.address@is.invalid> wrote:
> ...
>
> 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
| |
| Stephane CHAZELAS 2007-05-25, 7:17 am |
| 2007-05-24, 22:45(-04), Henry Townsend:
> Larry W. Virden wrote:
>
> 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 help here, it will only show a
bunch of leaves directly connected to the trunc (init).
--
Stéphane
|
|
|
|
|