Summary: | SIGALRM sometimes not delivered when using Konsole | ||
---|---|---|---|
Product: | [Applications] konsole | Reporter: | Soos Gergely <sogerc1> |
Component: | general | Assignee: | Konsole Developer <konsole-devel> |
Status: | RESOLVED INTENTIONAL | ||
Severity: | normal | CC: | adaptee, robertknight |
Priority: | NOR | ||
Version: | 1.6.6 | ||
Target Milestone: | --- | ||
Platform: | unspecified | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
Soos Gergely
2008-09-04 21:45:32 UTC
> 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. |