Am 02.07.16 um 18:56 schrieb Selva Nair: > > On Sat, Jul 2, 2016 at 11:32 AM, Arne Schwabe <a...@rfc2549.org > <mailto:a...@rfc2549.org>> wrote: > > > And why sighup? Shouldn't just limiting sec be enought. SIGHUP has many > > side effects. I don't think we should trigger these for connection time. > > > > > > With default setting this results in a SIGHUP after some hours and also > > the last intervals with 5120s are too big for default settings. I would > > aim for something lower like five or ten minutes. > > I think a bit about that and I think a good way to specify exponential > back is something like > > connect-retry 5 1800, which would mean "scale back up to 1800s" and > maybe default that option to connect-retry 5 300. That also allows > specifying larger connect-retry values without backoff. E.g. > connect-retry 60 60 > > > Good idea. > > Agreed, triggering SIGHUP is not ideal. The only reason for it was to > reset the counters so that the backoff time doesn't get stuck at the > highest value for ever. If we reduce the max backoff interval that's > less of a concern. > > One motivation for this patch is to avoid logs filling up. For a client > stuck in a restart loop with verb=3 and 5 minutes max pause, the logs > grow by about 1 M per day -- may be not too bad. > > Selva
Do you want to propose a new patch or should I do it. I would propose still a exponential backoff but starting a 2s. so we get 2s 4s 8s ... or as default conect-retry 2 256. It would then just stay at the 256s interval until a sucessful connection is established. That simplifies the logic and gives predictable (from a user perspective) results. Iirc the logic of connect-retry was changed by me in master so changing the logic again should not be a problem.
