# Sample verbose configuration file for Unicorn (not Rack) # # This configuration file documents many features of Unicorn # that may not be needed for some applications. See # http://unicorn.bogomips.org/examples/unicorn.conf.minimal.rb # for a much simpler configuration file. # # See http://unicorn.bogomips.org/Unicorn/Configurator.html for complete # documentation. # Note: If you change this file in a Merge Request, please also create a # Merge Request on https://gitlab.com/gitlab-org/omnibus-gitlab/merge_requests # Relative URL support # WARNING: We recommend using an FQDN to host GitLab in a root path instead # of using a relative URL. # Documentation: http://doc.gitlab.com/ce/install/relative_url.html # Uncomment and customize the following line to run in a non-root path # # ENV['RAILS_RELATIVE_URL_ROOT'] = "/gitlab" # Read about unicorn workers here: # http://doc.gitlab.com/ee/install/requirements.html#unicorn-workers # worker_processes 3 # Since Unicorn is never exposed to outside clients, it does not need to # run on the standard HTTP port (80), there is no reason to start Unicorn # as root unless it's from system init scripts. # If running the master process as root and the workers as an unprivileged # user, do this to switch euid/egid in the workers (also chowns logs): # user "unprivileged_user", "unprivileged_group" # Help ensure your application will always spawn in the symlinked # "current" directory that Capistrano sets up. working_directory "/home/git/gitlab" # available in 0.94.0+ # Listen on both a Unix domain socket and a TCP port. # If you are load-balancing multiple Unicorn masters, lower the backlog # setting to e.g. 64 for faster failover. listen "/home/git/gitlab/tmp/sockets/gitlab.socket", :backlog => 1024 listen "127.0.0.1:8080", :tcp_nopush => true # nuke workers after 30 seconds instead of 60 seconds (the default) # # NOTICE: git push over http depends on this value. # If you want to be able to push huge amount of data to git repository over http # you will have to increase this value too. # # Example of output if you try to push 1GB repo to GitLab over http. # -> git push http://gitlab.... master # # error: RPC failed; result=18, HTTP code = 200 # fatal: The remote end hung up unexpectedly # fatal: The remote end hung up unexpectedly # # For more information see http://stackoverflow.com/a/21682112/752049 # timeout 60 # feel free to point this anywhere accessible on the filesystem pid "/home/git/gitlab/tmp/pids/unicorn.pid" # By default, the Unicorn logger will write to stderr. # Additionally, some applications/frameworks log to stderr or stdout, # so prevent them from going to /dev/null when daemonized here: stderr_path "/home/git/gitlab/log/unicorn.stderr.log" stdout_path "/home/git/gitlab/log/unicorn.stdout.log" # Save memory by sharing the application code among multiple Unicorn workers # with "preload_app true". See: # https://www.rubydoc.info/gems/unicorn/5.1.0/Unicorn%2FConfigurator:preload_app # https://brandur.org/ruby-memory#copy-on-write preload_app true # Enable this flag to have unicorn test client connections by writing the # beginning of the HTTP headers before calling the application. This # prevents calling the application for connections that have disconnected # while queued. This is only guaranteed to detect clients on the same # host unicorn runs on, and unlikely to detect disconnects even on a # fast LAN. check_client_connection false require_relative "/home/git/gitlab/lib/gitlab/cluster/lifecycle_events" before_exec do |server| # Signal application hooks that we're about to restart Gitlab::Cluster::LifecycleEvents.do_master_restart end 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 # Signal application hooks that we're about to fork Gitlab::Cluster::LifecycleEvents.do_before_fork end # 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. # # This allows a new master process to incrementally # phase out the old master process with SIGTTOU to avoid a # thundering herd (especially in the "preload_app false" case) # when doing a transparent upgrade. The last worker spawned # will then kill off the old master process with a SIGQUIT. old_pid = "#{server.config[:pid]}.oldbin" if old_pid != server.pid begin sig = (worker.nr + 1) >= server.worker_processes ? :QUIT : :TTOU Process.kill(sig, File.read(old_pid).to_i) rescue Errno::ENOENT, Errno::ESRCH end end # # Throttle the master from forking too quickly by sleeping. Due # to the implementation of standard Unix signal handlers, this # helps (but does not completely) prevent identical, repeated signals # from being lost when the receiving process is busy. # sleep 1 end after_fork do |server, worker| # Signal application hooks of worker start Gitlab::Cluster::LifecycleEvents.do_worker_start # per-process listener ports for debugging/admin/migrations # addr = "127.0.0.1:#{9293 + worker.nr}" # server.listen(addr, :tries => -1, :delay => 5, :tcp_nopush => true) end