Hi,
I know that we can use sv stop unicorn then sv start unicorn to restart unicorn workers. But that will cause downtime. Killing the master with a USR2 signal is the usual way to do hot restart, as far as I know. Is it still safe to do that for Discourse? Or is there a better way to do this?
I understand that I rarely (or not at all) have to do this. But just want to know in case of emergency.
Thanks!
4 Likes
sam
June 27, 2017, 12:45am
2
Sort of, we do:
run("bundle exec rake themes:update assets:precompile")
using_s3_assets =
ENV["DISCOURSE_USE_S3"] && ENV["DISCOURSE_S3_BUCKET"] && ENV["DISCOURSE_S3_CDN_URL"]
run("bundle exec rake s3:upload_assets") if using_s3_assets
percent(80)
reload_unicorn(launcher_pid)
reloaded = true
# Flush nginx cache here - this is not critical, and the rake task may not exist yet - ignore failures here.
percent(85)
begin
run("bundle exec rake assets:flush_sw")
rescue RuntimeError
log "WARNING: Unable to flush service worker file"
end
percent(90)
log("Running post deploy migrations")
So you would send the USR2 to the unicorn launcher that will forward the signal for you.
1
end
def upgrade
return if @repos.any? { |repo| !repo.start_upgrading }
percent(0)
status("running")
clear_logs
log("********************************************************")
log("*** Please be patient, next steps might take a while ***")
log("********************************************************")
launcher_pid = unicorn_launcher_pid
master_pid = unicorn_master_pid
workers = unicorn_workers(master_pid).size
if workers < 2
log("ABORTING, you do not have enough unicorn workers running")
7 Likes
Ah. Sweet! That will do it. Thanks @sam !
tgxworld
June 27, 2017, 1:16am
4
USR2 - reexecute the running binary. A separate QUIT should be sent to the original process once the child is verified to be up and running.
@sam According to the docs, don’t we need to send a QUIT as well?
2 Likes
sam
June 27, 2017, 1:20am
5
3 Likes
This topic was automatically closed after 2538 days. New replies are no longer allowed.
