docker stop results in SIGTERM being sent #184

Activity

1. yosifkit commented on Aug 10, 2016

   

   yosifkit

   on Aug 10, 2016

   Member

   More actions

   I've not seen an issue in stopping a postgres container (though mine don't usually have much data or load) and so mine stop almost instantly after receiving SIGTERM. If you need more control, you could use docker kill -s TERM postgres, then you don't get the automatic KILL signal.
2. jjmata commented on Nov 2, 2016

   

   jjmata

   on Nov 2, 2016

   More actions

   I experience the same all the time, did you find a better solution @yntelectual?
3. rkrzewski commented on Dec 22, 2016

   

   rkrzewski

   on Dec 22, 2016

   More actions

   I had actually experienced data corruption because postgress process was SIGKILLed in the middle of flushing logs.
   Now, I always make sure to do docker exec -u postgres $CID pg_ctl stop instead of docker stop $CID
   Solving this correctly would require something along EXITPOINT hook described here moby/moby#6982, but sadly that feature seems to be abandoned.

   👍React with 👍4Reacted by Daniel van der Spuy, Sander Borsboom, David Perrenoud and Emmanuel S.
4. wglambert

   added

   Issue

   on Apr 24, 2018
5. tianon commented on May 7, 2018

   

   tianon

   on May 7, 2018

   Member

   More actions

   As referenced above, your best bet is to run docker kill -s TERM xyz directly and skip docker stop entirely (thus avoiding SIGKILL):

   I've not seen an issue in stopping a postgres container (though mine don't usually have much data or load) and so mine stop almost instantly after receiving SIGTERM. If you need more control, you could use docker kill -s TERM postgres, then you don't get the automatic KILL signal.

   Additionally, you might have luck with specifying --stop-timeout on the container itself to give docker stop a larger default, but I think that'll just be a stop-gap solution if it's taking longer than 60 seconds for your database to shut down. It sounds like you might have some architectural issues you'll want to look into to figure out why it's taking so long for your database to shut down.

   In the future, these sorts of questions/requests would be more appropriately posted to the Docker Community Forums, the Docker Community Slack, or Stack Overflow.

   👎React with 👎1Reacted by David Perrenoud
6. tianon

   closed this as completedon May 7, 2018
7. navossoc commented on Jun 5, 2018

   

   navossoc

   on Jun 5, 2018

   Last edited by navossoc

   More actions

   Well, as stated in https://www.postgresql.org/docs/10/static/server-shutdown.html:

   Smart Shutdown: ... lets existing sessions end their work normally. It shuts down only after all of the sessions terminate.

   So if the connection is idle in another process, 60 seconds may never be enough.

   About pg_ctl:

   Simply, the “smart” mode has been considered the default because it is the least distuptive, particularly it will wait for a backup to finish before shutting down the server. It has been (justly) discussed that it was not enough aggresive, users being sometimes surprised that a shutdown requested can finish with a timeout because a connection has been for example left open, hence the default has been switched to “fast”.

   https://paquier.xyz/postgresql-2/postgres-9-5-feature-highlight-pgctl-default-mode/

   Since we don't have a fine-grained shutdown control order in docker I'm using the stop_signal to change the behavior and get a clean shutdown with docker-compose.

   postgres:
     image: postgres:10.4-alpine
     container_name: postgres
     stop_signal: SIGINT                 # Fast Shutdown mode
   

   I think you can change the Dockerfile and specify the STOPSIGNAL.
   It should fix too...

   👍React with 👍7Reacted by Marcel Partap, Vladimir Chuprinskiy, Batuhan Bozkurt, David Perrenoud, Denis, Faraz and harmenkets

   ❤️React with ❤️1Reacted by Marcel Partap
8. tianon commented on Jun 5, 2018

   

   tianon

   on Jun 5, 2018 via email

   Member

   More actions

   Given that SIGTERM is more graceful (and less likely to break folks' databases), I'm wary of explicitly changing that.

   👍React with 👍1Reacted by Rafael Cossovan
9. navossoc commented on Jun 5, 2018

   

   navossoc

   on Jun 5, 2018

   More actions

   Sure, this is the safest choice. I'm not saying to change the default signal.

   What I really want to say is:

   As everyone should know their own application and their workload, that may be the tip someone needs to tweak their needs.