HUP => listen socket closes

[ThomasRogg]

In the current Icecast-kh13:

When sending the HUP signal, typically many things happen. It seems to temporarily close the listen socket and open it again.

However, there seems to be cases when this does not happen. Then the listen socket stays closed, till the HUP signal is sent some time later on.

To be more precise, when this happens, after the

INFO connection/connection_thread_shutdown shutting down connection thread

the following log entry does not happen

INFO connection/connection_thread connection thread finished

What could be the problem?

Thomas

[karlheyes]

indeed, sockets that are over 1024 (leftover from traditional unixen) should be closed and attempted to be re-opened. The reopen could fail if something is preventing it. If there is some other aspect causing say a hang then that is a different matter and would need investigating, however, if you just HUP again to get it working then that is not a hang. I'd need to see the log for the re-opening of sockets and what the current state of them are. I'm not aware of any delay that would prevent a binding

[ThomasRogg]

This actually happens quite often, so we had to downgrade to the last version we used. kh8 does not show this behaviour.

Why are listen sockets over 1024 closed at all?

[karlheyes]

I would like to see what actually happens in those cases. After checking, what should be happening is that unchanged sockets are left as-is, new ones added or old ones removed, but if you are saying that something else is going on then I'd like to see what the level 4 log says.

karl

[ThomasRogg]

We are using the kh13 again, and are sending a HUP signal whenever this happens. It is stable, but the problem must be fixed.

When it happens, after the following two messages:

[2020-06-01 06:30:51] INFO thread/ lock abort set to 0 [2020-06-01 06:30:51] INFO connection/connection_thread_shutdown shutting down connection thread

there are no messages related to the HUP signal processing. On the ones which work, we have the messages:

[2020-06-01 06:30:51] INFO thread/ lock abort set to 0 [2020-06-01 06:30:51] INFO connection/connection_thread_shutdown shutting down connection thread [2020-06-01 06:30:51] INFO connection/connection_thread connection thread finished [2020-06-01 06:30:51] INFO connection/connection_listen_sockets_close Leaving port 80 (178.162.200.9) open ... and more

I do not see any DBUG messages which are relevant to this..

Thomas

[karlheyes]

I think this is a caching issue, as part of this spills across different threads. I've committed into master a series of locks checks to hopefully deal with this. I suspet it may be more compiler/platform dependent.

karl.

[ThomasRogg]

Hi Karl! The problem still persists with 2.4.0-kh15. Do you have any idea on how I can give you enough information to fix this? I would like to do it myself, but I have no idea where to look. Regards, Thomas

[karlheyes]

hmm, The key things I'd need to know for sure is the xml, the log entries (level 4) and what the platform this is on. You could run strace (strace -o output -ff -tt -p $(pidof icecast)) while the HUP is sent (ie start strace, send HUP and then ctrl-C the strace). I suppose an xml setting could be added to avoid the close/open but that does not fix the issue.

karl.