From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/2484 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Jonathan de Boyne Pollard Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: How best to ensure s6-managed services are shut down cleanly? Date: Sat, 2 Feb 2019 02:19:42 +0000 Message-ID: <25b14650-8e6b-c113-f924-130c88778f35@NTLWorld.COM> References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------D8405812ED61F16B2AB1D1CF" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="143744"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 To: Supervision Original-X-From: supervision-return-2074-gcsg-supervision=m.gmane.org@list.skarnet.org Sat Feb 02 03:21:45 2019 Return-path: Envelope-to: gcsg-supervision@m.gmane.org Original-Received: from alyss.skarnet.org ([95.142.172.232]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1gpkwD-000bIH-FU for gcsg-supervision@m.gmane.org; Sat, 02 Feb 2019 03:21:45 +0100 Original-Received: (qmail 20473 invoked by uid 89); 2 Feb 2019 02:22:09 -0000 Mailing-List: contact supervision-help@list.skarnet.org; run by ezmlm Original-Sender: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 20466 invoked from network); 2 Feb 2019 02:22:09 -0000 X-Originating-IP: [86.10.101.211] X-Authenticated-User: J.deBoynePollard-newsgroups@NTLWorld.COM X-Spam: 0 X-Authority: v=2.3 cv=XubUx2N9 c=1 sm=1 tr=0 a=FQ5CjUvp3JFI4KFGyeqcZw==:117 a=FQ5CjUvp3JFI4KFGyeqcZw==:17 a=r77TgQKjGQsHNAKrUKIA:9 a=2rVjqWD_AAAA:8 a=j7q_F39RkRivub5vBHIA:9 a=QEXdDO2ut3YA:10 a=2kkyyvR4J4AA:10 a=-FEs8UIgK8oA:10 a=NWVoK91CQyQA:10 a=nD9ZPX3QeZiqCA3sCxAA:9 a=Ccp-9G56AnmNlj9Y:21 a=_W_S_7VecoQA:10 a=ULaUcM2Ibn9MdPUUwucP:22 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ntlworld.com; s=meg.feb2017; t=1549073982; bh=MdWDmkiMT8E0/bNcQNow7RWtroglbzNjt/3/WdLYquo=; h=Subject:To:References:From:Date:In-Reply-To; b=kJS+Y80hUv5f+OSagb0c2IVH2C/923Ko4q9RznQwAElKV6We7DQeklMOiOyHaBLWH /47OT9pWhgzwJuqF77a1rPVOinRf2JmiuhOSn6sGWWPOCif5Wf9Gsmh7OnqSiNKRaR XFONbIiLOof6auDNivjea+v8RBJZ7cORjatmFodC1FSMomiN/LYTiAYtaoOh2hBwZT ju7LAbdUHpvk4gAs9EjsqBu4u5YHTjNlG9/kknRQ3zycOafQLW853vtwcTn+e4fUvB CCAtapD31UkHTPyuJ50JAQdS6Ov3r9bktzyGsjEdFKjkyoI1dOVMPJI1pfNo8jjPGF uJQNGcl+Ny6EA== In-Reply-To: X-CMAE-Envelope: MS4wfKnwyznSgPlPBuAat25rFqOJ7ZMId3STtF/yamQJHns5UTx4V6oDWAkOv7YSfQPsuAVBoBpVawREBXTFziS01P4A+syb3bijk8nG5VgrZhjltJonTVvA mpQlrxAQbA6fLyhkGqBDg2WurQAUcVGQSG31CZLXxJ5lhYYMzlmvvnyQVhb/WqC9Mgg1+uJPovJ5U4GBPSKdSj7JBGZeYCtiuV4= Xref: news.gmane.org gmane.comp.sysutils.supervision.general:2484 Archived-At: --------------D8405812ED61F16B2AB1D1CF Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Laurent Bercot: > The question is, how does systemd decide to proceed with the rest of > the shutdown? > It waits for |s6-svscan| for up to 90s, putting the infamous cylon warrior and "A stop job is running for s6" message on the console. After 90s, it starts forcibly killing stuff, not necessarily in the right order because it does not know that PostgreSQL should be killed before |s6-svscan| and that main services are best taken down before log services. No, it will not wait forever for |s6-svscan| to exit. That is not a way to block it. I arrange things differently for running |service-manager| under systemd : % grep ExecStop /usr/local/lib/systemd/system/system-control-normal.service ExecStop=/bin/system-control start --verbose shutdown % |system-control| has all of the logic that knows to try harder if a |TERM| signal does not stop a service within 60s, and the |start| of |shutdown| stops running normal services because the |shutdown| service has |conflicts/| relationships with them. None of this logic is in the service manager itself, which does not need to know about timeouts and alternative signals, it comprising mechanism not policy. systemd will still try sending |TERM| signals to the service manager and force-killing stuff out of order, but because of an |After=| ordering only /after/ the |ExecStop| of |system-control-normal.service| has had its chance to shut things down in an orderly fashion. systemd does not even begin taking down the service manager until after |system-control| has attempted to shut down all managed services. --------------D8405812ED61F16B2AB1D1CF--