Is anyone aware of a utility that uses ptrace to attach to a process specified by PID, installs a signal handler for HUP that ignores it, and then untraces the subject process?
On Fri, 2006-09-08 at 11:30 -0500, David Nicol wrote:
Is anyone aware of a utility that uses ptrace to attach to a process specified by PID, installs a signal handler for HUP that ignores it, and then untraces the subject process?
WOuldn't a backtrace on a signal 7 do the same thing?
What does signal 7 have to do with HUP (Signal 1)?
On 9/8/06, Jason D. Clinton [email protected] wrote:
On Fri, 2006-09-08 at 11:30 -0500, David Nicol wrote:
Is anyone aware of a utility that uses ptrace to attach to a process
specified
by PID, installs a signal handler for HUP that ignores it, and then
untraces
the subject process?
WOuldn't a backtrace on a signal 7 do the same thing?
Kclug mailing list [email protected] http://kclug.org/mailman/listinfo/kclug
I must be thick. Can you connect the dots between the two signals?
On 9/10/06, Jason D. Clinton [email protected] wrote:
On Sat, 2006-09-09 at 21:00 -0500, Monty J. Harder wrote:
What does signal 7 have to do with HUP (Signal 1)?
If the objective is to get a trace on an already running process at the point of an event, then it would be a means to that end.
On Sun, 2006-09-10 at 20:57 -0500, Monty J. Harder wrote:
I must be thick. Can you connect the dots between the two signals?
There's nothing between them. If they absolutely _must_ use SIGHUP because, presumably, some third party program is sending it to their debugging target, then they can put a interceptor process's PID in place of the PID file of the debugging target that is being sought out. This interceptor would catch the HUP and emit a SEGV to the real PID. The perl/ruby and even C <signal.h> code for this is less than 10 lines.
If there is no third party program emitting SIGHUP, then it doesn't matter what signal is received and backtraced by gdb. SIGSEGV just happens to be the easiest one to do that with ...
On 9/10/06, Jason D. Clinton [email protected] wrote:
On Sun, 2006-09-10 at 20:57 -0500, Monty J. Harder wrote:
I must be thick. Can you connect the dots between the two signals?
There's nothing between them. If they absolutely _must_ use SIGHUP because, presumably, some third party program is sending it to their debugging target
ha ha ha ha ha
that third party program would be the sshd or the shell, whichever it is, and the signal will arive when I end the session, and the goal is not to ge a trace, but to ignore the signal. The retronohup utility is exactly what I was looking for.
On Mon, 2006-09-11 at 09:58 -0500, David Nicol wrote:
that third party program would be the sshd or the shell, whichever it is, and the signal will arive when I end the session, and the goal is not to ge a trace, but to ignore the signal. The retronohup utility is exactly what I was looking for.
So you started a daemon in a shell and wanted to avoid closing it. That might have helpful information to send along with your question.
-
David Nicol -
Jason D. Clinton -
Monty J. Harder