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
> trap 'echo bla' 14 ; /bin/kill -14 $$
This is unlikely to be a Linux kernel internal development
issue, which is what this "[email protected]"
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 <[email protected]> 1.925.600.0401
On Mon, 7 Nov 2005 17:36:29 +0000 (UTC),
Dick <[email protected]> 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
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!
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
Dick <[email protected]> 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.
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
Dick <[email protected]> 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.
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 ;-)
Dick <[email protected]> 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.