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? -- Although efforts are under way to mitigate the problem, this message may contain flippancy, hyperbole and/or confusing assertions. Please reply directly to fall2006sigfile@davidnicol.com for clarification of any points appearing unclear, vague, cruel, frustrating, threatening, negative, dilletantish or otherwise unprofessional before taking action based on misintepretation or misconstruction of such points.
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 <me@jasonclinton.com> 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 Kclug@kclug.org 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 <me@jasonclinton.com> 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 <me@jasonclinton.com> 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. -- Although efforts are under way to mitigate the problem, this message may contain flippancy, hyperbole and/or confusing assertions. Please reply directly to fall2006sigfile@davidnicol.com for clarification of any points appearing unclear, vague, cruel, frustrating, threatening, negative, dilletantish or otherwise unprofessional before taking action based on misintepretation or misconstruction of such points.
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.
participants (3)
-
David Nicol -
Jason D. Clinton -
Monty J. Harder