search

AllStarLink / app_rpt

Refactoring and upgrade of AllStarLink's app_rpt, etc.
9 stars 9 forks source link

With outstreamcmd= set, shutdown/restart of Asterisk is not reliable #338

Open jxmx opened 4 months ago

jxmx commented 4 months ago

With the "broadcastify" setup as documented with outstreamcmd, shutting down or restarting asterisk with systemctl is not reliable. It's either very slow or fails. Asterisk/app_rpt should be killing off any spawned processes at shutdown.

jxmx commented 4 months ago

The solution here is probably not to change app_rpt, but to make a monolithic item for app_rpt to kill on shutdown.

InterLinked1 commented 4 months ago

but to make a monolithic item for app_rpt to kill on shutdown.

What do you really mean by this, exactly?

The solution here is probably not to change app_rpt,

All Asterisk modules are expected to clean up anything they started. If app_rpt is not fully doing so when requested to unload, then it is a bug in my opinion.

jxmx commented 4 months ago

Could be. I haven't really spent time debugging yet. What APPEARS to be happening is that Asterisk/app_rpt is killing off the parent bash/sh process but then lame is re-parenting it's PID in a way that systemd is detecting as being part of the Asterisk group of PIDs but not to Asterisk/app_rpt. I was just thinking that a quick-and-easy fix might be to make sure that the Broadcastify process is a single-shot application that talks over a socket or something to the item that actually doing the lame/ezstream process.

pcpackrat commented 2 months ago

I noticed that when using outstreamcmd the CPU pegs at 100% when astres.sh is issued. I stopped using it for now.

Also the huge delay is quite normal for broadcastify style streaming. Even when using a local streaming server.