|Re: [chrony-dev] Patch: avoid infinite select() loop on chronyc|
[ Thread Index |
| More chrony.tuxfamily.org/chrony-dev Archives
- To: <chrony-dev@xxxxxxxxxxxxxxxxxxxx>
- Subject: Re: [chrony-dev] Patch: avoid infinite select() loop on chronyc
- From: Cristian Gafton <gafton@xxxxxxxxxx>
- Date: Mon, 4 Dec 2017 09:19:07 -0800
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; email@example.com; q=dns/txt; s=amazon201209; t=1512407975; x=1543943975; h=date:from:to:subject:in-reply-to:message-id:references: mime-version; bh=jRz5aMSpiXzTQtsoUF7oqzSa2votGOg01cNsweDHmzU=; b=s26Ed1sEufNDFsnWlvYnNq8pgJQozhSA8T+4AWUzQbLT+oKOGfFL5zEx Ox9XPxBLmoHtBT1KDw1MXV2NNtIvBxSd2sdDWNApr/afAXbzqQxAti7jD TqXCvMUaIlbWbR613YkIeyIjZ/dOhfjvmLjjfc8wkSN0jLL8CKXxhaPIt Q=;
On Mon, 4 Dec 2017, Miroslav Lichvar wrote:
I suspect the real problem is with the timeout. If it was negative,
select() would return EINVAL and the loop would not terminate. I guess
this could happen if chronyd (or something else) stepped the system
clock forward right between the first gettimeofday() call before the
request is sent and the second gettimeofday() call before select().
Could that be what happened in your case?
I think you are correct - there was a possibility of some clock step
happening on the system
I think the fix should be to check the timeout after its calculation.
If it is negative, a new attempt should be made.
I still think we need to limit bound the bnmber of attempts. Making the
assumption tat the next time around on a new attempt things will be
different is too risky. I'd rather have chronyc exit unsuccessfully than
keep trying forever the same codepath that already failed once...
To unsubscribe email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "unsubscribe" in the subject.
For help email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "help" in the subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxx.