Home > Archive > Unix Programming > November 2005 > Waiting on a daemonized process
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 |
Waiting on a daemonized process
|
|
| lambert54@cox.net 2005-11-22, 7:01 pm |
| I have a child process I start that daemonizes itself. I want to wait
on the daemon copy since the original one goes away and waitpid returns
as if the process ended, which it did of course. If I do a getprocs to
find the new process ID, will I be able to perform a waitpid on that
PID? I don't know if daemons are considered children anymore.
Thanks for any help.
| |
| Ilja Tabachnik 2005-11-22, 7:01 pm |
| lambert54@cox.net wrote:
> I have a child process I start that daemonizes itself. I want to wait
> on the daemon copy since the original one goes away and waitpid returns
> as if the process ended, which it did of course. If I do a getprocs to
> find the new process ID, will I be able to perform a waitpid on that
> PID? I don't know if daemons are considered children anymore.
AFAIK a process can wait (using, say, wait() or waitpid()) only for
it's child processes. You cannot just pick an arbitrary process, find out
it's PID and do a waitpid() for it.
HTH
--
Ilja.
| |
| Måns Rullgård 2005-11-22, 7:01 pm |
| Ilja Tabachnik <billy@arnis-bsl.com> writes:
> lambert54@cox.net wrote:
>
>
> AFAIK a process can wait (using, say, wait() or waitpid()) only for
> it's child processes. You cannot just pick an arbitrary process, find out
> it's PID and do a waitpid() for it.
That's correct.
--
Måns Rullgård
mru@inprovide.com
| |
| lambert54@cox.net 2005-11-22, 7:01 pm |
|
M=E5ns Rullg=E5rd wrote:
> Ilja Tabachnik <billy@arnis-bsl.com> writes:
>
ut[color=darkred]
>
> That's correct.
>
> --
> M=E5ns Rullg=E5rd
> mru@inprovide.com
I wound up spawning a thread which finds the process ID and uses getpri
to see if the process exists. If it does, then just sleep for 5 seconds
and try the getpri again. Don't know if there is a better way to
monitor an unrelated process but this seems to work fine. If anyone has
any other ideas please post them. Thanks.
BTW, I didn't post all the controls around this code for signaling
completion, etc. Just the basic check.
| |
| Måns Rullgård 2005-11-22, 7:01 pm |
| lambert54@cox.net writes:
> I wound up spawning a thread which finds the process ID and uses getpri
> to see if the process exists. If it does, then just sleep for 5 seconds
> and try the getpri again. Don't know if there is a better way to
> monitor an unrelated process but this seems to work fine. If anyone has
> any other ideas please post them. Thanks.
Polling a PID is generally not a good idea. It is possible that the
process dies, and the PID gets reused between two checks. If you need
to know when a particular process terminates, you have to arrange
other means. The simplest is usually creating it in such a way that
you can wait() for it. Pipes can also be used.
--
Måns Rullgård
mru@inprovide.com
| |
| David Schwartz 2005-11-22, 7:01 pm |
|
<lambert54@cox.net> wrote in message
news:1132695523.860583.120360@g47g2000cwa.googlegroups.com...
> I wound up spawning a thread which finds the process ID and uses getpri
> to see if the process exists. If it does, then just sleep for 5 seconds
> and try the getpri again. Don't know if there is a better way to
> monitor an unrelated process but this seems to work fine. If anyone has
> any other ideas please post them. Thanks.
This is not guaranteed to work. The "right way" to do it depends upon
why you're monitoring the other process and how much control you have over
it.
For example, if you're managing the other process to respawn it in case
it terminates in any way, you probably also want to deal with the case where
it stalls too. So it's best to test it somehow, rather than just check if it
exists. If it's a server, send it a dummy query. If you coded it, code it to
periodically touch a file and check the last modified time on that file.
Etcetera.
There may also be helpful non-portable tricks. For example, on Linux,
you can tell from 'proc' what executable a given process it running. This
will protect you against a new process with same PID, assuming it's a
different executable.
DS
| |
| lambert54@cox.net 2005-11-22, 7:01 pm |
|
M=E5ns Rullg=E5rd wrote:
> lambert54@cox.net writes:
>
>
> Polling a PID is generally not a good idea. It is possible that the
> process dies, and the PID gets reused between two checks. If you need
> to know when a particular process terminates, you have to arrange
> other means. The simplest is usually creating it in such a way that
> you can wait() for it. Pipes can also be used.
>
> --
> M=E5ns Rullg=E5rd
> mru@inprovide.com
Our department does not have control over the code in the process I am
starting and cannot change it. So, I have to make due with what we have
for the process itself. I use getprocs to get the PID based on the
process name. So, if the process dies and the ID is reused within 5
seconds then I have a problem. The only thing I could do is use
getprocs everytime to make sure the process name itself is still
hanging around.
| |
| Måns Rullgård 2005-11-22, 7:01 pm |
| lambert54@cox.net writes:
> Måns Rullgård wrote:
>
> Our department does not have control over the code in the process I am
> starting and cannot change it.
So walk over to the department that does control it, and have them
change it.
--
Måns Rullgård
mru@inprovide.com
| |
| joe@invalid.address 2005-11-22, 7:01 pm |
| lambert54@cox.net writes:
> Måns Rullgård wrote:
[color=darkred]
> Our department does not have control over the code in the process I
> am starting and cannot change it. So, I have to make due with what
> we have for the process itself. I use getprocs to get the PID based
> on the process name. So, if the process dies and the ID is reused
> within 5 seconds then I have a problem. The only thing I could do is
> use getprocs everytime to make sure the process name itself is still
> hanging around.
One possibility is to start it using a wrapper script that runs the
program as a coprocess. You can then use read -p to tell when it
exits. I've never actually done this, but I think it will work.
#!/bin/ksh
echo executing sleep as a coprocess
sleep 10 |&
echo sleep running
read -p dummy
echo sleep done
Of course, this assumes that the program you're running doesn't close
the pipe descriptor.
Joe
--
Gort, klatu barada nikto
| |
| Casper H.S. Dik 2005-11-22, 7:01 pm |
| lambert54@cox.net writes:
>I have a child process I start that daemonizes itself. I want to wait
>on the daemon copy since the original one goes away and waitpid returns
>as if the process ended, which it did of course. If I do a getprocs to
>find the new process ID, will I be able to perform a waitpid on that
>PID? I don't know if daemons are considered children anymore.
On systems with a properly functioning /proc you can likely use
the /proc filesystem or builtin tools.
E.g., Solaris has "pwait" for exactly this purpose.
(It opens a /proc/<pid>/psinfo file and then polls)
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
| |
| Konstantin Sorokin 2005-11-23, 3:57 am |
| David Schwartz <davids@webmaster.com> wrote:
> There may also be helpful non-portable tricks. For example, on Linux,
> you can tell from 'proc' what executable a given process it running. This
> will protect you against a new process with same PID, assuming it's a
> different executable.
>
On *BSD you can use kqueue(2) with EVFILT_PROC filter and NOTE_EXIT
to monitor processes.
--
Konstantin Sorokin
| |
| Dave Denholm 2005-11-23, 7:00 pm |
| lambert54@cox.net writes:
>
> I wound up spawning a thread which finds the process ID and uses getpri
> to see if the process exists. If it does, then just sleep for 5 seconds
> and try the getpri again. Don't know if there is a better way to
> monitor an unrelated process but this seems to work fine. If anyone has
> any other ideas please post them. Thanks.
>
I wonder if you can use ptrace() to attach to the process. Then you
can block [in wait() I think ?] waiting for the target to change
state. You'll presumably have to tell it to resume each time it stops
on a signal, but that may not be a problem.
- I assume it's ptrace() that truss / strace use to attach to
arbitrary pids ..?
dd
--
Dave Denholm <ddenholm@esmertec.com> http://www.esmertec.com
| |
| Casper H.S. Dik 2005-11-23, 7:00 pm |
| Dave Denholm <ddenholm@esmertec.com> writes:
>lambert54@cox.net writes:
[color=darkred]
>I wonder if you can use ptrace() to attach to the process. Then you
>can block [in wait() I think ?] waiting for the target to change
>state. You'll presumably have to tell it to resume each time it stops
>on a signal, but that may not be a problem.
>- I assume it's ptrace() that truss / strace use to attach to
>arbitrary pids ..?
ptrace() is old fashioned and arcane; some OSes still use it;
Solaris does not (Solaris doesn't have a ptrace system call, only
a library emulating ptrace on top of /proc).
Traditionally, ptrace() didn't allow attaching to non-children;
but that restriction was relaxed eons ago.
Attaching is sometimes seen as too heavy handed a tactic; it
does influence the process and may slow it down.
(But then, you may not have an option)
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
| |
| Frank Cusack 2005-11-23, 7:00 pm |
| On 22 Nov 2005 14:11:27 -0800 lambert54@cox.net wrote:
> Måns Rullgård wrote:
> Our department does not have control over the code in the process I am
> starting and cannot change it. So, I have to make due with what we have
> for the process itself. I use getprocs to get the PID based on the
> process name. So, if the process dies and the ID is reused within 5
> seconds then I have a problem. The only thing I could do is use
> getprocs everytime to make sure the process name itself is still
> hanging around.
Perhaps you do have enough control. You say that you are starting the
process, presumably this is via your own startup script. Well, it's
easy to start your own program that forks the process and waits for it.
This doesn't require any changes to the process you're waiting for.
-frank
| |
| Måns Rullgård 2005-11-23, 7:00 pm |
| Frank Cusack <fcusack@fcusack.com> writes:
> Perhaps you do have enough control. You say that you are starting the
> process, presumably this is via your own startup script. Well, it's
> easy to start your own program that forks the process and waits for it.
> This doesn't require any changes to the process you're waiting for.
If the program calls daemon(), you're out of luck.
--
Måns Rullgård
mru@inprovide.com
| |
| Frank Cusack 2005-11-23, 7:00 pm |
| On Wed, 23 Nov 2005 18:55:59 +0000 Måns Rullgård <mru@inprovide.com> wrote:
> Frank Cusack <fcusack@fcusack.com> writes:
>
>
> If the program calls daemon(), you're out of luck.
You can still get what you want with a shim for exec().
-frank
|
|
|
|
|