Re: Why would a kill -2 not work?
The pthread_* calls you are making aren't listed as being safe to run within the context of a signal handler, and could cause a thread waiting on that condition to be unblocked and start running. Please see earlier comments about mixing threads and signal handlers. Okay, fair enough. I'll rework our signal handler logic to avoid using any calls that are not considered signal-safe. Better to be safe than sorry... :-) Thanks for the feedback. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Why would a kill -2 not work?
Under what circumstances might a kill -2 nnn not work. I have a Python app with a signal handler configured to catch INT signals. It seems to work fine, but we've recently noticed that after the app has run for a while the kill -2 no longer works. This seems pretty suspicious, perhaps indicating our app is misbehaving in some way. What might cause the signal handler to stop working? Is there a better list for this question? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Why would a kill -2 not work?
Hi-- On May 18, 2009, at 9:23 AM, Peter Steele wrote: Under what circumstances might a kill -2 nnn not work. I have a Python app with a signal handler configured to catch INT signals. It seems to work fine, but we've recently noticed that after the app has run for a while the kill -2 no longer works. This seems pretty suspicious, perhaps indicating our app is misbehaving in some way. What might cause the signal handler to stop working? The main reason might be that your process is already in another signal handler or is otherwise blocked in a system call and won't get the new signal until it completes the current situation. The amount of stuff you're allowed to do safely in a signal handler is pretty minimal-- you're better off setting a flag, returning from the signal handler, and having the next run past the main event loop or whatever check for the flag and handle things in a normal app context. If you try to do anything involving malloc() or s/printf, etc, you're running risks. man sigaction is likely to be informative Regards, -- -Chuck ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Why would a kill -2 not work?
The amount of stuff you're allowed to do safely in a signal handler is pretty minimal-- you're better off setting a flag, returning from the signal handler, and having the next run past the main event loop or whatever check for the flag and handle things in a normal app context. If you try to do anything involving malloc() or s/printf, etc, you're running risks. man sigaction is likely to be informative This is basically what we doing. When the handler is triggered we set a global variable to indicate the system is shutting down. I also signal a condition to wake up a sleeping thread. The lack of log messages indicate that this handler never gets called and the system carries on as if the kill -2 never happened. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Why would a kill -2 not work?
Hi-- On May 18, 2009, at 2:45 PM, Peter Steele wrote: This is basically what we doing. When the handler is triggered we set a global variable to indicate the system is shutting down. I also signal a condition to wake up a sleeping thread. The lack of log messages indicate that this handler never gets called and the system carries on as if the kill -2 never happened. You're not trying to send a signal within the signal handler itself, are you? That won't work-- signal delivery is blocked when you're already running in a signal handler. Also, note that trying to mix signals with a multithreaded process is complicated -- -Chuck ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
RE: Why would a kill -2 not work?
What he said. It's better to just stick with -9; it almost always works! ;-) -Original Message- From: owner-freebsd-questi...@freebsd.org [mailto:owner-freebsd-questi...@freebsd.org] On Behalf Of Chuck Swiger Sent: Monday, May 18, 2009 4:49 PM To: Peter Steele Cc: #freebsd-questions Subject: Re: Why would a kill -2 not work? Hi-- On May 18, 2009, at 2:45 PM, Peter Steele wrote: This is basically what we doing. When the handler is triggered we set a global variable to indicate the system is shutting down. I also signal a condition to wake up a sleeping thread. The lack of log messages indicate that this handler never gets called and the system carries on as if the kill -2 never happened. You're not trying to send a signal within the signal handler itself, are you? That won't work-- signal delivery is blocked when you're already running in a signal handler. Also, note that trying to mix signals with a multithreaded process is complicated -- -Chuck ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org font size=1 div style='border:none;border-bottom:double windowtext 2.25pt;padding:0in 0in 1.0pt 0in' /div This email is intended to be reviewed by only the intended recipient and may contain information that is privileged and/or confidential. If you are not the intended recipient, you are hereby notified that any review, use, dissemination, disclosure or copying of this email and its attachments, if any, is strictly prohibited. If you have received this email in error, please immediately notify the sender by return email and delete this email from your system. /font ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Why would a kill -2 not work?
You're not trying to send a signal within the signal handler itself, are you? That won't work-- signal delivery is blocked when you're already running in a signal handler. Also, note that trying to mix signals with a multithreaded process is complicated No, I'm not sending a signal within a signal. The signal handler is this: pthread_mutex_lock(keep_running_mutex); KEEP_RUNNING = 0; pthread_cond_signal(keep_running_cond); pthread_mutex_unlock(keep_running_mutex); This works fine, but at some point it seems to stop working. The app just continues to run as if it never received the -2 signal. We have to use a kill -9 to kill it, which we want to avoid because this prevents our shutdown code from executing. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Why would a kill -2 not work?
On May 18, 2009, at 5:32 PM, Peter Steele wrote: No, I'm not sending a signal within a signal. The signal handler is this: pthread_mutex_lock(keep_running_mutex); KEEP_RUNNING = 0; pthread_cond_signal(keep_running_cond); pthread_mutex_unlock(keep_running_mutex); This works fine, but at some point it seems to stop working. The app just continues to run as if it never received the -2 signal. We have to use a kill -9 to kill it, which we want to avoid because this prevents our shutdown code from executing. The pthread_* calls you are making aren't listed as being safe to run within the context of a signal handler, and could cause a thread waiting on that condition to be unblocked and start running. Please see earlier comments about mixing threads and signal handlers. -- -Chuck ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
