[asterisk-dev] Asterisk Beacon Module Proposal

[George Joseph]

On Tue, May 12, 2015 at 10:08 AM, Jeffrey Ollie <jeff at ocjtech.us> wrote:

> On Tue, May 12, 2015 at 9:47 AM, George Joseph
> <george.joseph at fairview5.com> wrote:
> > On Tue, May 12, 2015 at 5:41 AM, Tzafrir Cohen <tzafrir.cohen at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20150512/306d027b/attachment.html>