Hi, On Wed, Sep 6, 2017 at 10:38 AM, RW <rwmailli...@googlemail.com> wrote: > 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.
Yes, thanks. Looks like pyzor is back online too. # pyzor ping public.pyzor.org:24441 (200, 'OK')