On Tue, 5 Sep 2017 19:36:05 -0400 Alex wrote: > Hi, > > >> > This is because the public server went offline today, thus the > >> > client waits until the default timeout which I think is 5 > >> > seconds. You can configure the timeout to something less. > >> > >> 5 seconds is pyzor's own default timeout (which you can change > >> via pyzor_options), but SA's default is to terminate it after 3.5 > >> seconds (pyzor_timeout). > > > > On Mon, 4 Sep 2017 20:11:56 -0400 > > Alex wrote: > > > >> check_pyzor: 4003 (81.1%) > > > > 4003 ms is suspiciously close to 4s. I'm wondering if Timeout.pm > > actually supports fractions of a second. > > I'm noticing the values are either 4003 or very close to that > throughout at least the last 48 hours. Perhaps the reason it's > SIGTERMd is because it's hit some timeout limit while it retries?
As I already said SA has its own timeout that terminates the pyzor process i.e. sends it a SIGTERM. The point about its being 4 seconds is that it's supposed to be 3.5, so it looks like it's being rounded. Looking at Timeout.pm it says that it based on alarm(2), so generally SA timeouts wont support fractions of a second.