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!
sam
(Sam Saffron)
27 juni 2017 om 00:45
2
Sort of, we do:
percent(80)
web_server.reload
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")
run("bundle exec rake multisite:migrate")
run("bundle exec rake s3:expire_missing_assets") if using_s3_assets
log_version_upgrade
percent(100)
So you would send the USR2 to the unicorn launcher that will forward the signal for you.
end
def reset!
@repos.each(&:stop_upgrading)
clear_logs
percent(0)
status(nil)
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("********************************************************")
Ah. Sweet! That will do it. Thanks @sam !
tgxworld
(Alan Tan)
27 juni 2017 om 01:16
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?