[asterisk-dev] Asterisk Beacon Module Proposal

[Jeffrey Ollie]

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.

-- 
Jeff Ollie