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

[jxmx]

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]

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

[InterLinked1]

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]

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]

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.