SIGALRM ignored

SIGALRM ignored

[Dick]

Hi all,

I've got a problem with SUSE LINUX Enterprise Server 9 (i586) patchlevel 2,
Linux 2.6.5-7.191-smp.

When I do the following (from bash):

trap 'echo bla' 14 ; /bin/kill -14 $$

nothing happens, utilities like iostat and netperf (and likely other utilities)
won't work due to this problem.

I've checked the glibc installation (rpm -V) and it's unchanged, bash and all
it's dependencies are also fine.

The kernel is unchanged from the SuSE LINUX Enterprise Server.

Could someone please help?

Thanks in advance,
Dick

Re: SIGALRM ignored

[Paul Jackson]

> trap 'echo bla' 14 ; /bin/kill -14 $$

This is unlikely to be a Linux kernel internal development
issue, which is what this "linux-kernel@vger.kernel.org"
list is focused on.  If I knew a good list to recommend
you ask this question on off the top of my head, I'd
recommend it.  Nothing jumps to mind.  Thought I'd at
least let you know that you might not get much help here,
and encourage you to research other possible resources.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.925.600.0401

Re: SIGALRM ignored

[Dick]

Paul Jackson <pj <at> sgi.com> writes:
> This is unlikely to be a Linux kernel internal development
> issue, which is what this "linux-kernel <at> vger.kernel.org"
> list is focused on.  

Yesterday I found the following issue:
http://www.vttoth.com/sigalrm.htm

which is kernel related, I will try to recompile the kernel for MPENTIUM4 and
see if it helps.

Does someone know a debugging technique to see whats happening?

Thanks,
Dick

Re: SIGALRM ignored

[Philippe Troin]

Dick <dm@chello.nl> writes:

> Paul Jackson <pj <at> sgi.com> writes:
> > This is unlikely to be a Linux kernel internal development
> > issue, which is what this "linux-kernel <at> vger.kernel.org"
> > list is focused on.  
> 
> Yesterday I found the following issue:
> http://www.vttoth.com/sigalrm.htm
> 
> which is kernel related, I will try to recompile the kernel for MPENTIUM4 and
> see if it helps.

I doubt it.

> Does someone know a debugging technique to see whats happening?

First make sure that you do not inherit a signal mask where SIGALRM is
blocked, and that you do not inherit a SIG_IGN signal disposition for
SIGALRM either.

Cat /proc/pid/status and look for the SigBlk line (blocked signals)
and the SigIgn (ignored signals).  SIGALRM is 14, look for bit 14,
that is 0000000000002000.  This bit should not be set.

Phil.

Re: SIGALRM ignored

[Dick]

Philippe Troin <phil <at> fifi.org> writes:
> > Does someone know a debugging technique to see whats happening?
> Cat /proc/pid/status and look for the SigBlk line (blocked signals)
> and the SigIgn (ignored signals).  SIGALRM is 14, look for bit 14,
> that is 0000000000002000.  This bit should not be set.

And it is set (SigBlk: 0000000000012000) ... Thank you very much, I have to
search in another direction.

Greetings,
Dick

Re: SIGALRM ignored

[Philippe Troin]

Dick <dm@chello.nl> writes:

> Philippe Troin <phil <at> fifi.org> writes:
> > > Does someone know a debugging technique to see whats happening?
> > Cat /proc/pid/status and look for the SigBlk line (blocked signals)
> > and the SigIgn (ignored signals).  SIGALRM is 14, look for bit 14,
> > that is 0000000000002000.  This bit should not be set.
> 
> And it is set (SigBlk: 0000000000012000) ... Thank you very much, I have to
> search in another direction.

Look at the display manager.  I know that wdm used to not clean up its
signals before starting a user session.

Phil.

Re: SIGALRM ignored

[Dick]

Philippe Troin <phil <at> fifi.org> writes:
> Look at the display manager.  I know that wdm used to not clean up its
> signals before starting a user session.

I've found the error, the signal was blocked in sshd and I was restarting sshd
from a ssh session, I also disabled some pam modules (which I suspect the block
came from). Restarting sshd from a console did the trick.

I don't know how to thank you ;-)

Re: SIGALRM ignored

[Philippe Troin]

Dick <dm@chello.nl> writes:

> Philippe Troin <phil <at> fifi.org> writes:
> > Look at the display manager.  I know that wdm used to not clean up its
> > signals before starting a user session.
> 
> I've found the error, the signal was blocked in sshd and I was restarting sshd
> from a ssh session, I also disabled some pam modules (which I suspect the block
> came from). Restarting sshd from a console did the trick.

Daemons like ssh should clean-up their signal masks on start-up.
Maybe you should file a bug against ssh?

> I don't know how to thank you ;-)

Then don't :-)

Phil.

Re: SIGALRM ignored

[Keith Owens]

On Mon, 7 Nov 2005 17:36:29 +0000 (UTC), 
Dick <dm@chello.nl> wrote:
>I've got a problem with SUSE LINUX Enterprise Server 9 (i586) patchlevel 2,
>Linux 2.6.5-7.191-smp.
>
>When I do the following (from bash):
>
>trap 'echo bla' 14 ; /bin/kill -14 $$
>
>nothing happens, utilities like iostat and netperf (and likely other utilities)
>won't work due to this problem.

Works for me on SLES9 SP2 ia64.

Linux chook 2.6.5-7.191-sn2 #1 SMP Tue Jun 28 14:58:56 UTC 2005 ia64 ia64 ia64 GNU/Linux
bash-2.05b-305.9

# trap 'echo bla' 14 ; /bin/kill -14 $$
bla

Re: SIGALRM ignored

[Dick]

Keith Owens <kaos <at> sgi.com> writes:
> Linux chook 2.6.5-7.191-sn2 #1 SMP Tue Jun 28 14:58:56 UTC 2005 ia64 ia64 ia64
GNU/Linux

I'm running a i686 kernel on a Xeon CPU... Thanks for testing!