Thanks for the very good suggestion on including signal handlers; I was aware
that this could be done in principle but was fuzzy on how to do it when using
libuv.
The OP referred to a TCP connection, but I discovered that the problem was not
due to the port closing, but rather the program itself halting. I found out
what my error was that was causing the program to halt was something silly - an
instruction to close a file handle was missing, so it kept creating new file
handles with every heartbeat, which (after 6 or 8 hours) would cause an error
and halt the program.
On Friday, August 7, 2020, 04:23:32 AM CDT, Ariel Machado
<[email protected]> wrote:
I assume you are talking about TCP connections, not UDP.
Are you saying that the listen port (server socket) stops accepting new fresh
connections or you're talking about an accepted connection that stops receiving
data after a period of inactivity?
If you are talking about an established connection, there may be a timeout
problem due to inactivity, in which case using keep alive (uv_tcp_keepalive)
should resolve the situation.
If you're talking about the socket that started listening for incoming
connections and stops accepting new connections after a while, it seems a
little strange, logs if uv_listen's callback (uv_connection_cb) is invoked and
what the status value is, or if your application was actually killed by an
unhandled signal.
About handling signal errors, you can use uv_signal_start, in addition
problably be a good idea handle SIGPIPE
(http://pod.tst.eu/http://cvs.schmorp.de/libev/ev.pod#The_special_problem_of_SIGPIPE)
You can use an approach like this:
int requested_shutdown;
uv_signal_t sig_int;
uv_signal_t sig_term;
void system_signals_start(void) {
signal(SIGPIPE, SIG_IGN);
uv_signal_init(uv_default_loop(), &sig_int);
uv_signal_init(uv_default_loop(), &sig_term);
uv_signal_start(&sig_int, signal_shutdown, SIGINT);
uv_signal_start(&sig_term, signal_shutdown, SIGTERM);
}
void system_signals_stop(void) {
uv_signal_stop(&sig_int);
uv_close((uv_handle_t *)&sig_int, NULL);
uv_signal_stop(&sig_term);
uv_close((uv_handle_t *)&sig_term, NULL);
}
static void signal_shutdown(uv_signal_t *handle, int code) {
fprintf(stderr, "Signal received: %d\n", code);
if ((code == SIGINT) || (code == SIGTERM))
requested_shutdown = 1;
}
void system_shutdown(void) {
system_signals_stop();
...
}
:
OK. I think my problem lies elsewhere; I think I have a bug in the program -
I think the program is crashing or getting a signal to quit. Then the port it
was listening on (of course) doesn't respond any more.
Are there any circumstances where something in libuv issues a SIGKILL, or other
signal, or something like that because it has detected an error?
On Thursday, August 6, 2020 at 2:23:16 AM UTC-5, Ben Noordhuis wrote:
On Wed, Aug 5, 2020 at 4:48 PM Bill Engelke <[email protected]> wrote:
>
> I have a program which acts as a server; I want it to listen on a port.
> Sometimes, many hours go by before any traffic comes to the port; I think
> this port is timing out and closing.
>
> What is the correct way to keep this port open when using libuv? I have
> looked at a variety of ways to do this (e.g., setting socket options, etc.)
> but I don't know which is best for use in libuv...
If the socket listens on a port (i.e., is a server socket), there
should be no issue with long periods of inactivity. (It's a different
story with peer sockets but I infer that's not what you mean.)
If the port becomes unreachable after a while, it's possible you have
a time-based firewall rule somewhere that closes it off.
--
You received this message because you are subscribed to the Google Groups
"libuv" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/libuv/5700f701-1cd4-426d-a4c5-e6e42d956423o%40googlegroups.com.
--
You received this message because you are subscribed to the Google Groups
"libuv" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/libuv/1630774454.1015585.1596814750176%40mail.yahoo.com.
