From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gentoo-dev+bounces-67329-garchives=archives.gentoo.org@lists.gentoo.org>
Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80])
	by finch.gentoo.org (Postfix) with ESMTP id 5056013877A
	for <garchives@archives.gentoo.org>; Fri, 22 Aug 2014 18:08:06 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
	by pigeon.gentoo.org (Postfix) with SMTP id 40A0AE0884;
	Fri, 22 Aug 2014 18:08:01 +0000 (UTC)
Received: from mail-vc0-f169.google.com (mail-vc0-f169.google.com [209.85.220.169])
	(using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
	(No client certificate requested)
	by pigeon.gentoo.org (Postfix) with ESMTPS id 09686E084C
	for <gentoo-dev@lists.gentoo.org>; Fri, 22 Aug 2014 18:07:59 +0000 (UTC)
Received: by mail-vc0-f169.google.com with SMTP id le20so12768725vcb.14
        for <gentoo-dev@lists.gentoo.org>; Fri, 22 Aug 2014 11:07:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:sender:in-reply-to:references:date:message-id:subject
         :from:to:content-type;
        bh=UZ8JEW5QjtIkxo5qI3bctkQ+xPlCf2/J29OKQNTWTRg=;
        b=g5dq5Z51+6EoE9ukfbJT6drZXihwn8qby5hDbcQP3hMk7J52Ss8emeZOQyLVwc0WS4
         oPHxqwZL9C6HWLJi9J3q7jv2BM2QWIm9olumQ+oUvVG9pYdF+BLafoKSou2b4EZxlDAx
         dPf7M/bM0X//z/U08/YVjJ7Ncs04AYdtbk6nY4k2c2e+QOwO2qU1l9S8kbNHAzOKP5O/
         Tbg1Snj3KqV40EgfZ4lULb9i3kx61p4a+krahvou9+Yt2dPXl5w2j9D7BN5euV7ulkdF
         xLDOS+a6ycR2C/7LNaW7hMJEZm+xNI83JWm+yzhyzcXix+Mx1u/uVoPiPmVXGHezXSm0
         BRBg==
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
X-BeenThere: gentoo-dev@lists.gentoo.org
Reply-to: gentoo-dev@lists.gentoo.org
MIME-Version: 1.0
X-Received: by 10.52.129.165 with SMTP id nx5mr4006938vdb.25.1408730878897;
 Fri, 22 Aug 2014 11:07:58 -0700 (PDT)
Sender: freemanrich@gmail.com
Received: by 10.52.8.229 with HTTP; Fri, 22 Aug 2014 11:07:58 -0700 (PDT)
In-Reply-To: <20140822172318.GA24962@gengoff.gsmr1.local>
References: <53C51107.8090308@gentoo.org>
	<1405424184.1378.1.camel@gentoo.org>
	<53C52422.9070308@gentoo.org>
	<20140822172318.GA24962@gengoff.gsmr1.local>
Date: Fri, 22 Aug 2014 14:07:58 -0400
X-Google-Sender-Auth: 2arlOJjTQt8JpqpaD-OQBMEpQew
Message-ID: <CAGfcS_nD+mVnYO290LJrPwFMiMjM_pK1teZKd8YNdd6SPDO7bA@mail.gmail.com>
Subject: Re: [gentoo-dev] systemd + postgresql is non-obvious to me
From: Rich Freeman <rich0@gentoo.org>
To: gentoo-dev <gentoo-dev@lists.gentoo.org>
Content-Type: text/plain; charset=UTF-8
X-Archives-Salt: 393abc40-5162-4904-b95c-8c92fbafc6b8
X-Archives-Hash: a7c5c362591ee43b18b900608adfcfaf

On Fri, Aug 22, 2014 at 1:23 PM, Aaron W. Swenson <titanofold@gentoo.org> wrote:
> On the whole, I'm displeased with the systemd alternative for
> controlling PostgreSQL. It's significantly hampered and doesn't allow
> as much flexibility as the initscript. The major issue being trying to
> nicely shut down the server instead of jumping straight to murder.
>

It looks like the package installs a service file provided by
upstream, so you might want to direct your complaint there unless it
really is a systemd limitation.

Checking the latest version in portage it calls:
ExecStop=/usr/@LIBDIR@/postgresql-@SLOT@/bin/pg_ctl stop -D
${DATA_DIR} -s -m fast

I'm no postresql expert, but according to the manpage that should
bring the server to a screeching, but still controlled, halt.  Perhaps
you would prefer setting it to -m smart instead of -m fast.

If so override it in /etc/systemd/system.  I generally recommend using
drop-ins for this, but I'm not sure if doing a drop-in for ExecStop
will override the existing value, or simply cause systemd to run both
commands (which means that whichever runs first will control how it
stops).

Systemd shouldn't begin killing processes without mercy until the
process invoked in ExecStop terminates, so it should not terminate
until the process has finished graceful shutdown.

Rich