References: <1467430368-25437-1-git-send-email-selva.nair@...277...> <94cf2582-6f60-4b3f-0675-c362f2d91238@...1227...> From: Arne Schwabe Message-ID: Date: Sun, 3 Jul 2016 00:38:46 +0200 MIME-Version: 1.0 In-Reply-To: Subject: Re: [Openvpn-devel] [PATCH] Exponentially backoff on repeated connect retries List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit To: Selva Nair Cc: "openvpn-devel@lists.sourceforge.net" Am 02.07.16 um 18:56 schrieb Selva Nair: > > On Sat, Jul 2, 2016 at 11:32 AM, Arne Schwabe > 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.