I'd like to see the following feature in Centova: forcefully kill an app which occupies a port so that server (or sc_trans) can be started.

The problem is: sometimes after an account is terminated their server still runs (for unknown reason it was not stopped; happens pretty rare). When another account is created with the same port number, the server for this account can not be started as the port is occupied by an old process. In order to solve this, we have to manually SSH to the server and kill that process. If Centova could forcefully free the ports by killing those processes, that would be great.

We recently discovered a bug in which, if a server/source process is not responding and therefore does not stop with a SIGTERM, Centova Cast would fail to send a SIGKILL to the process (as it was designed to do).  That's most likely why some processes weren't terminating upon account deletion, and if so, that won't happen any more.

As for your proposed solution, the problem with that is that there's no guarantee the process using the port was started by Centova Cast.  And if it's not running under the 'ccuser' account, Centova Cast would need root privileges to kill it, which it doesn't have.  Therefore that's not possible, I'm afraid.

I mean only killing processes that were started by Centova. Well, if you say that bug is fixed - that's great. I hope it will work as intended now. Thanks.

The bug is still there. Sometimes shoutcast/sc_trans/icecast/whatever crash but the process stays and occupy the port. Because of this Auto DJ and/or server can not be restarted - "port already in use". This is extremely annoying as our staff has to SSH to the server and "kill" those idle processes, so that server can be started. Until then, station is offline. Should I say customers are not very happy about this?
Again, this is extremely annoying. Solution is needed urgently.

I'm not sure why Centova can't simply kill those processes. If we have server which runs on a known port(s), and this port is busy - then Centova has to free it. If the server is configured correctly - then this port number can only be used by that server software.

As for your proposed solution, the problem with that is that there's no guarantee the process using the port was started by Centova Cast.

On a properly configured server it will be a process created by Centova (server or autodj software).

I agree. Centova currently doesn't kill sc_trans/sc_serv procesess

This bug is still there, and the more users we have, the more support tickets we get about it. People can't [re]start their server and/or AutoDJ software.

2015-04-27 14:05:08   E   msg:[MAIN] Error opening port 8456 because Could not bind to :8456 because Address already in use
2015-04-27 14:05:08   E   msg:API server startup error. Could not bind to :8457 because Address already in use

It's the typical log contents when trying to start sc_trans. People do nothing wrong with their control panels and they get problems for nothing. Stations are offline, sometimes for a long time (8+hours) as not everyone here who does support have root access to servers to fix it (security measure).

The resolution

2014-08-20 - Won't fix; Can't implement without root privs

is not acceptable. Why not create a daemon which runs with root rights and does the job? Or cron job which checks a list of ports which need to be freed and kill the processes. The way it is now is not good at all and I'm really getting tired of it.

This bug is still there

No, the bug you originally reported is not still there.

and the more users we have, the more support tickets we get about it. People can't [re]start their server and/or AutoDJ software.

You seem to be referring to a completely different issue now.  Originally you said streams were not stopped when they were terminated.  Now you seem to say they aren't stopped when users restart their server or autoDJ.  If that's the case, please open a ticket with the helpdesk, as that's an unrelated problem.

The resolution

2014-08-20 - Won't fix; Can't implement without root privs

is not acceptable. Why not create a daemon which runs with root rights and does the job?

Several reasons:
1) Because that would be a bandaid fix -- we're not going to implement an entire new application just to clean up the side effects of a problem rather than fixing the root problem;
2) Because thousands of other clients are not encountering this issue, leading me to beleive it's something specific to your servers or your usage scenarios;
3) Because root privileges are not needed to kill processes that were launched by Centova Cast, which is what you're talking about now.

Please open a support ticket to have someone look at your server the next time this happens.  We can't assist without seeing what's going on.

You seem to be referring to a completely different issue now.  Originally you said streams were not stopped when they were terminated.  Now you seem to say they aren't stopped when users restart their server or autoDJ.  If that's the case, please open a ticket with the helpdesk, as that's an unrelated problem.

Steve, thanks for replying. The problem is still the same, it's just another part of it. The cause is: some processes are not killed, holding the port and preventing server software to start.

1) Because that would be a bandaid fix -- we're not going to implement an entire new application just to clean up the side effects of a problem rather than fixing the root problem;

If the root cause can be found - it would be great. But a "band aid" fix would do too, if it fixes the problem. Customers don't care how it's fixed. All they care about if it works or not. Ugly solution is better than no solution at all.

2) Because thousands of other clients are not encountering this issue, leading me to beleive it's something specific to your servers or your usage scenarios;

Nothing special with usage: server is dedicated to Centova, all packages are standard...

3) Because root privileges are not needed to kill processes that were launched by Centova Cast, which is what you're talking about now.

Yes, it's Centova processes which hold the ports. Apart from Centova no other stuff is running on those servers.

Please open a support ticket to have someone look at your server the next time this happens.  We can't assist without seeing what's going on.

I'll try it, thanks. Are there any logs I should send/look at?