<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 12, 2015 at 10:59 AM, Tzafrir Cohen <span dir="ltr"><<a href="mailto:tzafrir.cohen@xorcom.com" target="_blank" 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>></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 10:39:04AM -0600, George Joseph wrote:<br>
> On Tue, May 12, 2015 at 10:08 AM, Jeffrey Ollie <<a href="mailto:jeff@ocjtech.us" 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>> wrote:<br>
><br>
> > 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>
> > ><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,<br>
> > 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>
> ><br>
> ><br>
> Hmmm. It just seems to me we're way over thinking this. Separate<br>
> executables and a public APIs seems overkill for something that on;y needs<br>
> to run for a few seconds on startup and reload.<br>
<br>
Why does it only need to run on startup and reload? Shouldn't it<br>
send stats periodically?<br>
<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div>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.</div><div><br></div></div></div></div>