summaryrefslogtreecommitdiff
path: root/config/unicorn.rb.example.development
diff options
context:
space:
mode:
authorJan Provaznik <jprovaznik@gitlab.com>2019-06-26 17:42:24 +0200
committerJan Provaznik <jprovaznik@gitlab.com>2019-07-01 09:05:31 +0200
commit52223d59515bc16c4c412a26929d2efd76759b4f (patch)
treef8646b865b0dec84cc37559551d480d1adde23a4 /config/unicorn.rb.example.development
parent66313aec761e48f4bf28461b760daa7774025fcf (diff)
downloadgitlab-ce-puma-init-restart.tar.gz
Run before_fork only once on bootpuma-init-restart
This aligns behavior of before_fork with Puma where before_fork is called only on master boot, also none of our code needs to be run before each worker fork, instead we have a use-case for deleting Prometheus files only on boot time.
Diffstat (limited to 'config/unicorn.rb.example.development')
-rw-r--r--config/unicorn.rb.example.development15
1 files changed, 8 insertions, 7 deletions
diff --git a/config/unicorn.rb.example.development b/config/unicorn.rb.example.development
index 1ff55701c14..9a02d5f1007 100644
--- a/config/unicorn.rb.example.development
+++ b/config/unicorn.rb.example.development
@@ -25,17 +25,18 @@ run_once = true
before_fork do |server, worker|
if run_once
+ # There is a difference between Puma and Unicorn:
+ # - Puma calls before_fork once when booting up master process
+ # - Unicorn runs before_fork whenever new work is spawned
+ # To unify this behavior we call before_fork only once (we use
+ # this callback for deleting Prometheus files so for our purposes
+ # it makes sense to align behavior with Puma)
run_once = false
- # The Unicorn before_exec hook only gets called on a Unicorn
- # restart, but we want to clean things up (e.g. metric files) at
- # first boot.
- Gitlab::Cluster::LifecycleEvents.do_master_restart
+ # Signal application hooks that we're about to fork
+ Gitlab::Cluster::LifecycleEvents.do_before_fork
end
- # Signal application hooks that we're about to fork
- Gitlab::Cluster::LifecycleEvents.do_before_fork
-
# The following is only recommended for memory/DB-constrained
# installations. It is not needed if your system can house
# twice as many worker_processes as you have configured.