Thanks, that makes sense. One thing that I don't understand is what situations in normal Asterisk operation would cause a SIGHUP to get sent to the daemon. I'm getting a lot of these deadlocks, and I'm suspicious that there is a problem somewhere else causing me to get an abnormal volume of SIGHUPs. I will do more tracing to track that down, but do you know of anything in normal operation that would cause a large volume of SIGHUPs?
<br><br>Thanks for the help,<br><br>Jay<br><br><div><span class="gmail_quote">On 9/24/06, <b class="gmail_sendername">Tilghman Lesher</b> <<a href="mailto:tilghman@mail.jeffandtilghman.com">tilghman@mail.jeffandtilghman.com
</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">On Saturday 23 September 2006 22:18, Jay Hoover wrote:<br>> Can anyone enlighten me about why ast_module_reload needs to be
<br>> called from the SIGHUP handler? I see that this was added quite a<br>> few years ago (may '01), but I can't find anything in the code that<br>> explains the reasoning behind it.<br><br>Generally speaking, SIGHUP on many daemon processes today causes the
<br>configuration files to be re-read. The 'reload' routine in modules<br>generally does that operation. Given that we have an alternative<br>method of effecting a reload from the bash command line ('asterisk -rx<br>reload'), I don't see the handling of SIGHUP in this way to be
<br>critical.<br><br>--<br>Tilghman<br>_______________________________________________<br>--Bandwidth and Colocation provided by <a href="http://Easynews.com">Easynews.com</a> --<br><br>asterisk-dev mailing list<br>To UNSUBSCRIBE or update options visit:
<br> <a href="http://lists.digium.com/mailman/listinfo/asterisk-dev">http://lists.digium.com/mailman/listinfo/asterisk-dev</a><br></blockquote></div><br>