Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Set the RTSP socket to close on exec() of child processes #329

Closed
mikeshir opened this issue Jun 22, 2016 · 7 comments
Closed

Set the RTSP socket to close on exec() of child processes #329

mikeshir opened this issue Jun 22, 2016 · 7 comments

Comments

@mikeshir
Copy link

... otherwise background run_this_before_play_begins | run_this_after_play_ends commands that are sleeping prevent the daemon from being restarted because the listening RTSP port is still in use.

diff --git a/rtsp.c b/rtsp.c
index e78456f..46de66c 100644
--- a/rtsp.c
+++ b/rtsp.c
@@ -1839,6 +1839,7 @@ void rtsp_listen_loop(void) {
continue;
}

  • fcntl(fd, F_SETFD, FD_CLOEXEC);
    ret = setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, &yes, sizeof(yes));

ifdef IPV6_V6ONLY

@mikebrady
Copy link
Owner

Thanks. I'll get to this in a couple of days.

@mikebrady
Copy link
Owner

mikebrady commented Jun 26, 2016

Hi there. I'm afraid I don't understand this. Could you explain it a bit more please?

[Update] Are you saying that a sleeping run_this_before_play_begins or a run_this_after_play_ends process will keep the port in use when main program is terminated?

@mikeshir
Copy link
Author

mikeshir commented Jun 26, 2016

Yes, that's what I'm saying. And /etc/init/d/sahirport-sync restart doesn't work as a result. I use the callbacks to turn my amps on and off and I sleep in the after_play callback. That fcntl() sets the file descriptor to close automatically if any of the exec...() functions are called.

@mikebrady
Copy link
Owner

mikebrady commented Jun 27, 2016

Thanks for that – I've incorporated it into 2.8.4.3 which is out now, on the development branch. (BTW, using the same reasoning, I guess I should also be closing any open file descriptors. Is that correct, do you think?)

@mikeshir
Copy link
Author

It shouldn't matter for open files unless you open them exclusively using file locking. I don't think you do since that one line fixed my problem. The listening socket on a specific port is the only exclusive resource that cannot be shared and therefore needs to be released.

@mikebrady
Copy link
Owner

Thanks.

@mikebrady
Copy link
Owner

There have been many updates since this, and I'm pretty sure the problem has been resolved. Please open a new issue if necessary.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants