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! Cheers, Brett -- Brett Neumeier (bneume...@gmail.com)