On 07/31, Dave Jones wrote:
>
> Since 3.5, I've started noticing weird things happening with signal delivery.
> Things I've seen so far..
>
> - long running tasks SIGINT, even though I wasn't even anywhere near the keyboard.
> - processes running inside screen/tmux disappearing (and taking the whole session with them).
>
> And now, while waiting for a kernel to build I just saw..
>
> /bin/sh: line 1: 3274 Hangup gcc
Currently I have no idea where this change could come from...
Well, not sure this will help... but if you can reproduce this,
may be you can identify the sender of the wrong SIGHUP at least.
cd /sys/kernel/debug/tracing/
echo "sig==1" >> events/signal/signal_generate/filter
echo 1 >> options/stacktrace
echo 1 >> events/signal/signal_generate/enable
cat trace_pipe > SIGHUP_TRACE
and then rebuild the kernel.
Oleg.
On Wed, Aug 01, 2012 at 05:11:34PM +0200, Oleg Nesterov wrote:
> On 07/31, Dave Jones wrote:
> >
> > Since 3.5, I've started noticing weird things happening with signal delivery.
> > Things I've seen so far..
> >
> > - long running tasks SIGINT, even though I wasn't even anywhere near the keyboard.
> > - processes running inside screen/tmux disappearing (and taking the whole session with them).
> >
> > And now, while waiting for a kernel to build I just saw..
> >
> > /bin/sh: line 1: 3274 Hangup gcc
>
> Currently I have no idea where this change could come from...
>
> Well, not sure this will help... but if you can reproduce this,
> may be you can identify the sender of the wrong SIGHUP at least.
>
> cd /sys/kernel/debug/tracing/
> echo "sig==1" >> events/signal/signal_generate/filter
> echo 1 >> options/stacktrace
> echo 1 >> events/signal/signal_generate/enable
> cat trace_pipe > SIGHUP_TRACE
>
> and then rebuild the kernel.
I'll give that a shot when I'm back on running kernel of the day.
Right now, I'm bisecting something that requires an hour or so of testing
between each step, so that's pretty much written off this week.
Dave
Oleg Nesterov <[email protected]> writes:
> [...]
> Well, not sure this will help... but if you can reproduce this,
> may be you can identify the sender of the wrong SIGHUP at least.
>
> cd /sys/kernel/debug/tracing/
> echo "sig==1" >> events/signal/signal_generate/filter
> echo 1 >> options/stacktrace
> echo 1 >> events/signal/signal_generate/enable
> cat trace_pipe > SIGHUP_TRACE
FWIW, just in case your ftrace subsystem is already busy, this
two-liner is equivalent:
# stap -o SIGHUP_TRACE -e 'probe kernel.trace("signal_generate")
{ if ($sig==1) print_backtrace() }'
- FChE