On Tue, May 12, 2015 at 9:47 AM, George Joseph <george.jos...@fairview5.com> wrote: > On Tue, May 12, 2015 at 5:41 AM, Tzafrir Cohen <tzafrir.co...@xorcom.com> > wrote: >> >> On Mon, May 11, 2015 at 01:29:04PM -0600, George Joseph wrote: >> >> > As for the other issues, why not just have asterisk fork itself on >> > startup >> > and reloads just to send the stats. No separate executables, no AMI, no >> > cron, and you get the process separation so a segv or orthe rerror >> > doesn't >> > kill the main process. >> > >> > KISS! >> >> This makes it part of the asterisk service, as far as systemd is >> concerned. > > Is that a bad thing? Did I miss something in the email chain?
I wouldn't call it a "bad" thing, it's just an implementation choice that has its pluses and minuses. If the main Asterisk process forks a copy of itself systemd will track the subprocess and kill it off when shutting down the main service. However, you then need to add to Asterisk code to keep track of the subprocess, reap the process if the subprocess dies and restart the subprocess. You'd still need some sort of remote API for the subprocess to gather the statistics from the main process, but it wouldn't have to be stable, even between minor releases, because each side would always be running the same code.. Personally, I'd go with an external process that's a separate binary (or could even be written in a scripting language) that talks to an API presented by Asterisk. The stats API would need to be a little more stable, but that wouldn't be a bad thing either. -- Jeff Ollie -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev