On Tue, May 12, 2015 at 10:59 AM, Tzafrir Cohen <tzafrir.co...@xorcom.com> wrote:
> On Tue, May 12, 2015 at 10:39:04AM -0600, George Joseph wrote: > > 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. > > Why does it only need to run on startup and reload? Shouldn't it > send stats periodically? > > The only volatile stats to be reported were active/total calls and I'd be willing to give that up to keep the process simple. Even if we did keep the calls, and it reported a few times a day I still don't see the need for the complexity. I don't want to have to set up cron jobs and worry about extra services or have to go through exposing new APIs. In the time we've been discussing this, a basic module that does what we needed could have been written.
-- _____________________________________________________________________ -- 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