On Tue, May 12, 2015 at 10:08 AM, Jeffrey Ollie <j...@ocjtech.us> wrote:
> 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. > > Hmmm. It just seems to me we're way over thinking this. Separate executables and a public APIs seems overkill for something that on;y needs to run for a few seconds on startup and reload.
-- _____________________________________________________________________ -- 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