Asterisk作为SIP代理间歇性无征兆退出问题求助

Let’s break down your problem step by step—you’ve got Asterisk working as a SIP proxy with basic registration/call functionality, but it’s exiting unexpectedly (no core dumps, no segfaults) specifically when there are no connected users, and after restarting you see a last qualify 0 message for the last connected user. Here’s how to dig into this:

1. Check for Exit Triggers in Configurations #

Asterisk doesn’t normally exit just because there are no active SIP users, so start by hunting for custom logic that might force a shutdown:

• Open your extensions.conf and search for any system() or exec() calls tied to user unregistration or zero active calls. For example, a line like exten => h,1,System(asterisk -rx 'core stop now') would trigger an exit when the last call hangs up.
• Check asterisk.conf for unusual settings like exitonclose (typically for console sessions, but worth verifying) and scan modules.conf for custom modules that handle user lifecycle events.

2. Crank Up Logging to Catch the Exit Event #

Without crash dumps, detailed logs are your best clue to what’s happening right before Asterisk exits:

• Edit logger.conf to set verbose = 5 and debug = yes, then restart Asterisk. This will log every SIP event, module activity, and system signal.
• Monitor system logs (e.g., /var/log/syslog or /var/log/messages) for lines like asterisk[PID]: Received signal 15 (Terminated)—this would mean an external process is sending a shutdown signal to Asterisk.
• Use the live console with asterisk -rvvvv to watch real-time activity when you manually disconnect the last SIP user. You might spot a critical message right before it exits.

3. Dig Into SIP Qualify Behavior #

That last qualify 0 message suggests the last user was marked unreachable due to a failed qualify check. Let’s tie that to the exit:

• If using chan_sip, check sip.conf for qualify settings (e.g., qualify=3000) and any autodestroy or notify options that trigger actions when a user becomes unreachable.
• For PJSIP users, inspect endpoint configurations in pjsip.conf—look for on_unregistration or on_registration_failure hooks that could execute shutdown commands.
• Run sip show peers (chan_sip) or pjsip show endpoints (PJSIP) while users are connected, then watch how their status changes when they disconnect. Note if the exit happens immediately after a user is marked UNREACHABLE.

4. Rule Out System Resource Limits #

Asterisk might exit silently if it hits resource limits, even without a crash dump:

• Check file handle limits with ulimit -n (run as the asterisk user). If it’s low (e.g., 1024), increase it by adding these lines to /etc/security/limits.conf:

  asterisk soft nofile 65535
  asterisk hard nofile 65535
  

• Monitor memory usage with top or htop while Asterisk runs. If memory creeps up over time, there could be a leak in a custom module or buggy third-party add-on.

5. Check Monitoring/Restart Tools #

Sometimes external tools are the unexpected culprit:

• If using systemd to manage Asterisk, look at your service file (e.g., /etc/systemd/system/asterisk.service). Check the Restart parameter—if set to Restart=on-abnormal, a low-resource idle state might be misclassified as abnormal.
• Check for cron jobs or monitoring tools like monit that might stop/restart Asterisk when idle. Run crontab -u asterisk -l to see scheduled tasks.

6. Test the Scenario Manually #

Reproduce the issue intentionally to narrow it down:

• Register a single SIP user, then force them offline (e.g., turn off their phone or block their IP). Watch Asterisk closely to see if it exits immediately.
• If it does, use strace to trace system calls right before exit: strace -p $(pidof asterisk)—this will show exactly what commands Asterisk runs when shutting down.

7. Verify Asterisk Version & Patches #

Check if this is a known bug in your version:

• Run asterisk -V to get your version number, then confirm if there are reported bugs about unexpected exits with no active users. Many older versions (pre-16.x) had edge cases with SIP user lifecycle handling fixed in later releases. Consider upgrading to the latest stable build if you’re on an older version.

内容的提问来源于stack exchange，提问作者JayMan89