Hi, I am running busybox's NTPD and noticed that it sometimes exits. Enabling debugs I see the following logs:
ntpd: sending query to 10.255.254.13 ntpd: sending query to 10.255.254.11 ntpd: reply from 10.255.254.13: offset:-1.049563 delay:0.002000 status:0x24 strat:4 refid:0x0bfeff0a rootdelay:0.020172 reach:0x03 ntpd: setting time to 2020-09-23 06:59:38.341065 (offset -1.049563s) ntpd: recv(10.255.254.11) error: Bad file descriptor Looking at the code, what I think is happening is that we receive replies from .11 and .13 almost simultaneously, in the same poll() call. So we are the loop processing the fds from the poll() call here: for (; nfds != 0 && j < i; j++) { if (pfd[j].revents /* & (POLLIN|POLLERR)*/) { ... nfds--; recv_and_process_peer_pkt(idx2peer[j]); ... First we process the reply from .13, so we call recv_and_process_peer_pkt() which calls update_local_clock() and step_time(). We can verify that by the log "setting time to 2020-09-23 06:59:38.341065 (offset -1.049563s)". Then I think we may be going inside this condition: for (item = G.ntp_peers; item != NULL; item = item->link) { peer_t *pp = (peer_t *) item->data; reset_peer_stats(pp, offset); //bb_error_msg("offset:%+f pp->next_action_time:%f -> %f", // offset, pp->next_action_time, pp->next_action_time + offset); pp->next_action_time += offset; if (pp->p_fd >= 0) { /* We wait for reply from this peer too. * But due to step we are doing, reply's data is no longer * useful (in fact, it'll be bogus). Stop waiting for it. */ close(pp->p_fd); pp->p_fd = -1; set_next(pp, RETRY_INTERVAL); } and hence closing the socket of .11. Finally we return to the loop where we process the FDs from the poll, and we try to recv from .11, which is closed and set to -1. Could that be the problem? Thanks, Stavros _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox