Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mk68n-0007sP-J7 for pgsql-admin@arkaria.postgresql.org; Mon, 08 Nov 2021 15:00:57 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mk68m-00037R-GT for pgsql-admin@arkaria.postgresql.org; Mon, 08 Nov 2021 15:00:56 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mk68m-00037I-6T for pgsql-admin@lists.postgresql.org; Mon, 08 Nov 2021 15:00:56 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mk68f-0002N8-J0 for pgsql-admin@lists.postgresql.org; Mon, 08 Nov 2021 15:00:55 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 1A8F0il5890134; Mon, 8 Nov 2021 10:00:44 -0500 From: Tom Lane To: Lynn Carol Johnson cc: "pgsql-admin@lists.postgresql.org" Subject: Re: Postgres dying after many failed logins In-reply-to: <58143128-71A6-4C51-9BCD-35105A385FA8@cornell.edu> References: <58143128-71A6-4C51-9BCD-35105A385FA8@cornell.edu> Comments: In-reply-to Lynn Carol Johnson message dated "Mon, 08 Nov 2021 12:45:07 +0000" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <890132.1636383644.1@sss.pgh.pa.us> Date: Mon, 08 Nov 2021 10:00:44 -0500 Message-ID: <890133.1636383644@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Lynn Carol Johnson writes: > My question: Is this expected behavior, ie that the server will > shutdown after hours of failed attempts? There is nothing built-in that would cause that, and frankly I doubt that there is any direct connection. It could be that the AWS environment imposes some resource limit (i.e., total number of child processes spawned) that the postmaster is eventually hitting because of the hack attempts. However, if that's true, I wouldn't really expect it to manifest as anything as polite as a SIGTERM signal. So I think there is something else going on. You need to look for what in your environment could send the postmaster a SIGTERM. Can you correlate the shutdown with anything? One thing I'm wondering is if it matches the time of shutdown of whatever you're launching the postmaster with. regards, tom lane