Version: 1.6.6 (using 3.5.10, Kubuntu (hardy) 4:3.5.10-0ubuntu1~hardy1) Compiler: Target: i486-linux-gnu OS: Linux (i686) release 2.6.20-15-386 The most unfortunate thing is that I cannot reproduce the error and I cannot tell what causes it. I have a perl script that relies on an alarm signal being delivered to it. From time to time it is not delivered. At first I thought I made a programming error so I wrote a really simple test script but that also does not receive the signal neither with the "alarm" system call nor with the "kill" command (but the TERM and INT signal does). The only thing I can do to resolve this is to log out and log in again. Funny thing is that while the script does not receive the signal under konsole, if I switch to a character terminal the script works fine. The even funniest thing is that if I start xterm from konsole then the signal is not delivered but if I start xterm from the run dialog (using Alt+F2) then the signal is delivered. Please, at least give me some clue how to resolve this thing.
> The most unfortunate thing is that I cannot reproduce the error > and I cannot tell what causes it. There is probably not a lot I can do to help you in that case. If you do find a way to reproduce it reasonably reliably then please attach your script.
I wrote a small C code to test whether this is a perl hiccup and the answer is that it is not. Because I really need that alarm signal I spent a lot of time searching the internet for any clue but the eureka came when I noticed a difference in konsole's /proc/*/status when the signal is delivered and when it isn't. When SIGALRM is not delivered there is a line saying: SigBlk: 0000000000002000 When SIGALRM is delivered you can see only zeros. After a lot of searching I found out that this could mean that the alarm signal is blocked. I have to confess I did not know that signals can be blocked and what's even worse: the list of blocked signals is inherited from the parent process (the manpage for sigaction should state this in huge block letters). Now that I do know the solution is easy: use POSIX; $sigset = POSIX::SigSet->new; $sigset->fillset(); sigprocmask(SIG_UNBLOCK,$sigset); very similar to what you would do in a C code. I also found out that the source of this issue does not come from konsole but kdeinit (I saw that the /proc/*/exe links to /usr/bin/kdeinit for the konsole's process and if I start konsole from an xterm the issue disappears). Somehow (erroneously I guess) kdeinit blocks the alarm signal and while I can do a workaround in my script other people may not be as lucky if they find this issue in a compiled C code provided by a distribution. I still can't tell when and why is the alarm signal blocked. Please respond if you think I can do anything to help.
Hi Sergio, You can reset the SIGALRM signal handler back to the default either in the shell (from which the perl script is started) or probably in the Perl script itself. See the "How to handle a signal" section on this page: http://affy.blogspot.com/p5be/ch13.htm . The example they give for resetting a signal handler back to the default is: $SIG{'INT'} = 'DEFAULT'; You should find that this bug will not occur in KDE 4 because Konsole resets all signal handlers in the child process back to the default on startup.
Resetting the signal action is not enough since the signal is blocked! You have to unblock it with sigprocmask(). Does Konsole in kde4 also unblock every signal at startup?
Sorry, didn't read your previously reply carefully. No Konsole doesn't unblock signals. I can change Konsole to do that of course.
That would be great and definitely solves my initial problem but the question still remains why does kdeinit block the alarm signal in the first place? I don't know the internal structure of kdeinit, I don't know if it uses the ALARM signal or not but if it doesn't then you can close this bug report. If it uses it and the signal is erroneously blocked then we may have to do further investigations. My script uses knotify to notify the users on various actions and if my script detects that knotify is not running (which is the case on my computer after login, I'm not sure why) it starts knotify like this: kdeinit knotify Do you think that the alarm signal remains blocked because my script starts knotify in an "unpleasant" time? (This is just a guess.)
A bug report from 3 years ago :) It is not hard for konsole to unblock signals, but I suspect that is something an emulator is supposed to do. IMHO, if an app relies upon some signals being delieverd, it is that app's reponsibility to check and unblock those signals on startup. Forgetting to do so should be seen as a bug of that app. If konsole unblock signals as suggested, those bugs will be hidden by the extra convenience provided by konsole. I will close this report as WONTFIX. Feel free to reopen if you have different and sensible idea.