From owner-freebsd-stable@FreeBSD.ORG Fri Nov 7 12:29:57 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 22889C9F for ; Fri, 7 Nov 2014 12:29:57 +0000 (UTC) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D6043B92 for ; Fri, 7 Nov 2014 12:29:56 +0000 (UTC) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Xmife-0005iU-GM; Fri, 07 Nov 2014 13:29:47 +0100 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: gmx@ross.cx, petefrench@ingresso.co.uk, stable@freebsd.org Subject: Re: Advice on an odd networking problem References: Date: Fri, 07 Nov 2014 13:29:41 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: User-Agent: Opera Mail/12.17 (Win32) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: - X-Spam-Score: -1.0 X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED, BAYES_40 autolearn=disabled version=3.3.1 X-Scan-Signature: 5a1627636b35b65657045ef62631cd80 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 12:29:57 -0000 On Fri, 07 Nov 2014 13:20:45 +0100, Pete French wrote: >> My guess from "https" + "proportion of calls" + "503": >> Maybe you run out of random data for ssl connections. >> Thus nginx waits for more random data, times out, apache times out -> >> 503 ? > > I didnt know it would do that - interesting. But in this case the https > is on the outside only - those calls are succeeding, its the intrenal > ones, which are http only, which are failing. > > -pete. I quote your original story: 'We have 5 machines running webservers - apache24 serving cgi scripts, plyus nginx being used to drive uwsgi with some django/python based code. These are load balanced by pound on a machine which faces the internet. This all works as expected, except that if I modify the cgi-scripts running inside Apache so they make some https calls to the nginx server on 127.0.0.1 then what we see is that pound then stops being able to connect to Apache for a proportion of its calls - its returns 503's.' First you say Apache makes https calls to nginx on 127.0.0.1 and now you say https is on the outside only. I find it hard to discuss if you change the story halfway through. So, what is actually taking to long and results in a 503 from where? You need to figure that out. Regards, Ronald.