<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 12, 2015 at 10:08 AM, Jeffrey Ollie <span dir="ltr"><<a href="mailto:jeff@ocjtech.us" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=jeff@ocjtech.us&cc=&bcc=&su=&body=','_blank','location=yes,menubar=yes,resizable=yes,width=800,height=600');return false;">jeff@ocjtech.us</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, May 12, 2015 at 9:47 AM, George Joseph<br>
<<a href="mailto:george.joseph@fairview5.com" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=george.joseph@fairview5.com&cc=&bcc=&su=&body=','_blank','location=yes,menubar=yes,resizable=yes,width=800,height=600');return false;">george.joseph@fairview5.com</a>> wrote:<br>
> On Tue, May 12, 2015 at 5:41 AM, Tzafrir Cohen <<a href="mailto:tzafrir.cohen@xorcom.com" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=tzafrir.cohen@xorcom.com&cc=&bcc=&su=&body=','_blank','location=yes,menubar=yes,resizable=yes,width=800,height=600');return false;">tzafrir.cohen@xorcom.com</a>><br>
> wrote:<br>
>><br>
>> On Mon, May 11, 2015 at 01:29:04PM -0600, George Joseph wrote:<br>
>><br>
>> > As for the other issues, why not just have asterisk fork itself on<br>
>> > startup<br>
>> > and reloads just to send the stats.  No separate executables, no AMI, no<br>
>> > cron, and you get the process separation so a segv or orthe rerror<br>
>> > doesn't<br>
>> > kill the main process.<br>
>> ><br>
>> > KISS!<br>
>><br>
>> This makes it part of the asterisk service, as far as systemd is<br>
>> concerned.<br>
><br>
> Is that a bad thing?  Did I miss something in the email chain?<br>
<br>
I wouldn't call it a "bad" thing, it's just an implementation choice<br>
that has its pluses and minuses.  If the main Asterisk process forks a<br>
copy of itself systemd will track the subprocess and kill it off when<br>
shutting down the main service.  However, you then need to add to<br>
Asterisk code to keep track of the subprocess, reap the process if the<br>
subprocess dies and restart the subprocess.  You'd still need some<br>
sort of remote API for the subprocess to gather the statistics from<br>
the main process, but it wouldn't have to be stable, even between<br>
minor releases, because each side would always be running the same<br>
code..<br>
<br>
Personally, I'd go with an external process that's a separate binary<br>
(or could even be written in a scripting language) that talks to an<br>
API presented by Asterisk.  The stats API would need to be a little<br>
more stable, but that wouldn't be a bad thing either.<br>
<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div>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.</div><div><br></div></div></div></div>