supervision - discussion about system services, daemon supervision, init, runlevel management, and tools such as s6 and runit
 help / color / mirror / Atom feed
From: "Laurent Bercot" <>
To: "Arjun D R" <>,
Subject: Re: Query on S6 system shutdown
Date: Thu, 29 Jul 2021 11:33:08 +0000	[thread overview]
Message-ID: <em9cfc82f3-8af9-4d46-8ec5-0bb6d75eb021@elzian> (raw)
In-Reply-To: <>

>I believe the finish script is not being called by s6-svc. When I run it
>manually , the finish script runs and kills the process and graceful
>shutdown is happening as expected.
>What may be the cause for not triggering the finish script of critical

  The finish script, which is entirely optional, is not supposed to
kill the process. It is not called by s6-svc, and does not run when
the process is still alive. It is *not* equivalent to the "down"
script of a oneshot. (There is a subtle hint in the fact that the
scripts are named "run" and "finish" instead of "up" and "down".)

  If it exists, the finish script is run by s6-supervise *after* the
service dies. The point is to perform any potentially needed cleanups
that are not automatically performed at service death.

  Your current finish script is entirely incorrect and you should
delete it.

  In order to kill your service, you need to send it a signal. Daemons
normally have a signal that tells them to gracefully exit; for most
daemons, it is SIGTERM, which is what svc -d sends by default.

  If your critical.service does not die on s6-svc -d, it means that
it ignores SIGTERM. Then you need to find out *what* signal it
interprets as a request for a graceful shutdown, and put the name
of this signal in the "down-signal" file in your service definition
directory. Then, when you send s6-svc -d, critical.service will
receive the signal you indicated.

  down-signal can be SIGKILL - this is what you're using at the moment -
but if your service is that critical, chances are it's not the best way
to kill it and you should look for a gentler signal to send it first.
If there are cases where a graceful exit request is ignored or takes
too long, and you want to make sure the service dies at some point,
you can create a "timeout-kill" file, containing a number of 
- if the process is still alive after that duration after receiving
its down-signal, it will be sent a SIGKILL.


      reply	other threads:[~2021-07-29 11:33 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-29  8:43 Arjun D R
2021-07-29 11:33 ` Laurent Bercot [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=em9cfc82f3-8af9-4d46-8ec5-0bb6d75eb021@elzian \ \ \ \
    --subject='Re: Query on S6 system shutdown' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).