Asterisk 1.6 produces *many* zombie processes on Debian.

Home » Asterisk Users » Asterisk 1.6 produces *many* zombie processes on Debian.
Asterisk Users 3 Comments

Am 20.12.2010 21:39, schrieb Ernie Dunbar:
> We have an issue with our Asterisk install where Asterisk produces many
> Zombie processes (on the order of several hundred per minute) until either
> the Asterisk server is restarted (and the zombies die a natural death), or
> the kernel runs out of PID space (happens within hours) and brings the
> system to a halt.
>
> This problem only happens when the server is under some non-trivial load.
> We were testing this server with 8 SCCP phones, making up to five
> simultaneous calls through the DAHDI interface (a Digium Wildcard
> TE410P/TE405P (1st Gen)). Once our customers (nearly all SIP clients)
> start logging on and we get around 7 or 8 simultaneous DAHDI calls,
> Asterisk starts producing zombie processes at a high rate.
>
> We are using the following software:
>
> Debian Lenny 5.0
> Asterisk 1.6.2.15
> `dahdi show version`: DAHDI Version: 2.4.0 Echo Canceller: MG2
> Libpri 1.4.11.4
>
> A2Billing is also installed on this server, if that matters at all.
>
> Any help with this issue, including help in troubleshooting the cause, is
> highly appreciated.

What does /var/log/asterisk/messages say? And /var/log/syslog?

3 thoughts on - Asterisk 1.6 produces *many* zombie processes on Debian.

  • Not much. In /var/log/asterisk/messages here’s a lot of lines like this:

    [Dec 17 19:10:13] NOTICE[25518] chan_sip.c: Registration from
    ‘ failed for ‘XX.XXX.X.XXX’ – No matching
    peer found

    And /var/log/syslog has all the normal output from a2billing.php and
    making calls complete and such.

    The other funny thing is that except for the massive number of zombie
    processes, calls are being made and completed just fine. Even voice
    quality is quite high.

  • Actually, no. This is part of a migration, and those are mostly customers’
    secondary lines (which for the most part, aren’t even active). We get a
    lot of these bad logins because the retry times on the ATAs are quite
    short.

    Asterisk really *shouldn’t* leave zombies around for every bad login, but
    if it does, then I suppose cleaning up these missing accounts might fix
    it.