How best to ensure s6-managed services are shut down cleanly?

From: Brett Neumeier <>
Date: Fri, 1 Feb 2019 12:25:04 -0600

I use s6 to supervise userspace services like RabbitMQ and PostgreSQL. The
s6-svscan process is launched and managed by systemd (because it's a CentOS
7 system).
What I would like to do is ensure that PostgreSQL is shut down cleanly when
the system is being powered down or rebooted. Because of the way that
PostgreSQL handles signals, the best way to do that is to send it a SIGINT
and then wait for the main server process to terminate.

I _think_ that with my naive current setup, what actually happens is:

- systemd sends a SIGTERM to s6-svscan;
- s6-svscan sends a SIGTERM or SIGHUP to all s6-supervise processes,
depending on what they are supervising, and then runs the finish program;
- the s6-supervise for postgresql sends a SIGTERM and a SIGCONT to the main
database process. It then waits for the postgresql process to terminate,
runs its finish program if there is one, and exits;
- because postgresql responds to SIGTERM by disallowing new connections but
permitting existing ones to keep running, it continues doing that until
being killed.

Reviewing the current docs for s6, I see that I can improve this situation
a bit by using a "down-signal" file to tell s6-supervise to send a SIGINT
instead of a SIGTERM. That's cool! But what I would really _like_ to do is
wait for up to a minute to allow the database to shut down cleanly before
the system shutdown proceeds -- something more like...

s6-svc -Oic -wd -T60000 /path/to/svcdir || s6-svc -Oq -wd /path/to/svcdir

Is there an elegant way to get that to happen?

It seems like maybe I could do that by running s6-svscan with the -s
option, and writing a .s6-svscan/SIGTERM handler, or by putting the
commands I want to run in the s6-svscan finish script, but if there's a
better option I am really curious to know it!



Brett Neumeier (
Received on Fri Feb 01 2019 - 18:25:04 UTC

This archive was generated by hypermail 2.3.0 : Sun May 09 2021 - 19:44:19 UTC