Asterisk 12 – Zombie Processes

Home » Asterisk Users » Asterisk 12 – Zombie Processes
Asterisk Users 13 Comments

Hello Asterisk users, We noticed that on Asterisk 12 zombie processes are being generated – They are released after a while, but we have around 10-20 zombie processes running.

We are not sure if this is a normal behavior or an issue.

We saw in the documentation that the bridging module creates zombie processes – is it related?

Thank you, Yaron.

13 thoughts on - Asterisk 12 – Zombie Processes

  • Hello Mathew, In the following tutorial it says that channel are marked with ZOMBIE flag. From your response I assume it has no connection to my problem. https://wiki.asterisk.org/wiki/display/AST/Asterisk+12+Bridging+Project

    Regrading the zombie processes issue we are having. We have debug taken from the server during such process is invoked. If you want I can attache it.

    Furthermore, in recent days we have had a number of reboots. Most of our servers are on release 12.2.0.RC1, and we have just upgraded to 12.6.1 on one of the servers. since the upgrade we have’t had a reboot, but it is too early to be sure.

    Somehow the core files are not written – in the log file it says –
    Executable ‘/ivr/app/asterisk/sbin/asterisk’ doesn’t belong to any package. Do you have any idea?

    Thank you, Yaron.

  • A zombie channel has nothing to do with a process. It was an artefact of an internal process known as a masquerade. While masquerades do sometimes still occur in Asterisk 12+, they are far less frequent and are no longer externally visible.

    Why do you think you have zombie processes? Asterisk does use a large number of threads, but generally rarely forks processes unless you are using something like original AGI.

  • Mathew, When I run ‘ps -ef|grep asterisk’ the following processes are displayed:
    root 6861 1 0 Aug27 ? 00:00:00 /bin/sh
    /ivr/app/asterisk/sbin/safe_asterisk -U asterisk -G asterisk -C
    /ivr/app/asterisk/etc/asterisk/asterisk.conf asterisk 8062 6861 3 Oct27 ? 00:44:56
    /ivr/app/asterisk/sbin/asterisk -f -U asterisk -G asterisk -C
    /ivr/app/asterisk/etc/asterisk/asterisk.conf -vvvg -c root 20776 2200 0 11:20 pts/2 00:00:33 tail -f asterisk.log asterisk 23076 8062 0 17:01 ? 00:00:00 [asterisk]
    asterisk 23897 8062 0 17:03 ? 00:00:00 [asterisk]

    also when I run top the same amount of zombie processes are displayed:
    Tasks: 185 total, 1 running, 182 sleeping, 0 stopped, 2 zombie

    Regarding the AGI – we are using AGI in order to run php scripts for external logic. I have printed the PIDs of the php scripts and none of them are related to the PID’s of those zombie processes. Do you have any idea how to find out what are these processes?
    Yaron.

  • Hello Mathew and everyone, We are still having reboots on our asterisk servers. The latest 12.6.1
    release doesn’t fix the issue.

    We have the core files of the latest reboots and also debug taken during the reboot.

    We would like to open an issue. What kind of information you need for the issue?

    Thanks, Yaron.

  • No, I went over all my scripts.

    Thanks for the help.

    Yaron

    On Wed, Oct 29, 2014 at 6:11 PM, Paul Belanger

  • Hello Asterisk users & developers, I have opened an issue few days ago regarding the crash and the zombie processes. I haven’t received any response and it has’t been assigned. If something is wrong or missing with the issue please get back to me and I
    will handle it.

    Please look into it because we still have crashes every day or two, and we can’t reproduce the issue in our lab with a simulator.

    Thank you, Yaron.

  • To set expectations here:

    This is an open source project. No one is under any obligation to look at your issue.

    There are currently around 20 issues or so in the issue tracker in Triage. Bug marshals are working through those issues as fast as they can, but generally they work from oldest to newest. If an older issue takes a lot of investigation… well, there’s only so many hours in a day.

    Even after an issue is triaged, that is not a guarantee that someone will fix your issue. It is a crash, and that generally means it is higher priority – however, if you can’t reproduce it in a lab environment or provide instructions on how it is reproduced, then you have to hope that a developer who does look at it can infer the cause of the crash from the information available. Any information you can provide beyond the backtrace on how to reproduce the issue will help a developer who looks at it.

    Again, however, no one is under any obligation to fix the issue. If you need more assurance that your issue is resolved, I’d highly recommend looking at issuing a bug bounty [1], or contacting a developer in the Asterisk Developer Community for assistance.

    [1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Bug+Bounties

  • Mathew, We are aware that this is an open source product, and our expectations are clear. All we are asking is that once there is someone assigned to the issue, he will guide us in what other data or tests should be performed in order to diagnose and fix the issue in the shortest time.

    Sorry if the message is not understood. Yaron