- Get service status
- Tail process logs
- Starting and stopping
- Invoking Rake tasks
- Starting a Rails console session
- Starting a PostgreSQL superuser psql session
- Container Registry garbage collection
The following commands can be run after installation.
sudo gitlab-ctl status; the output should look like this:
run: nginx: (pid 972) 7s; run: log: (pid 971) 7s run: postgresql: (pid 962) 7s; run: log: (pid 959) 7s run: redis: (pid 964) 7s; run: log: (pid 963) 7s run: sidekiq: (pid 967) 7s; run: log: (pid 966) 7s run: unicorn: (pid 961) 7s; run: log: (pid 960) 7s
After Omnibus GitLab is installed and configured, your server will have a runit
service directory (
runsvdir) process running that gets started at boot via
/etc/inittab or the
/etc/init/gitlab-runsvdir.conf Upstart resource. You
should not have to deal with the
runsvdir process directly; you can use the
gitlab-ctl front-end instead.
You can start, stop or restart GitLab and all of its components with the following commands.
# Start all GitLab components sudo gitlab-ctl start # Stop all GitLab components sudo gitlab-ctl stop # Restart all GitLab components sudo gitlab-ctl restart
Note that on a single-core server it may take up to a minute to restart Unicorn and Sidekiq. Your GitLab instance will give a 502 error until Unicorn is up again.
It is also possible to start, stop or restart individual components.
sudo gitlab-ctl restart sidekiq
Unicorn supports zero-downtime reloads. These can be triggered as follows:
sudo gitlab-ctl hup unicorn
If you are using Puma, Puma does support almost zero-downtime reloads. These can be triggered as follows:
sudo gitlab-ctl hup puma
Note that you cannot use a Unicorn/Puma reload to update the Ruby runtime.
Puma and Unicorn have different signals to control application behavior:
|reloads config file and gracefully restart all workers||reopen log files defined, or stop the process to force restart|
|stops request processing immediately||gracefully stops requests processing|
|reopen all logs owned by the master and all workers||restart workers in phases, a rolling restart, without config reload|
|reexecute the running binary||restart workers and reload config|
|exit the main process||exit the main process|
The behavior of graceful restart (
gitlab-ctl hup unicorn and
gitlab-ctl hup puma) is defined as follow:
Unicorn: a sequence of
SIGQUITsignals are sent to Unicorn,
Puma: a sequence of
SIGTERM(if process does not restart) signals are sent to Puma.
There are structural differences in handling of graceful restart (
gitlab-ctl hup) between
Unicornstarts a new process, but continues processing requests on old master, it stops accepting connections once
Pumastops accepting new connections as soon as
SIGINTis received. It finishes all running requests. Then
runitrestarts the service.
To invoke a GitLab Rake task, use
gitlab-rake. For example:
sudo gitlab-rake gitlab:check
sudo if you are the
Contrary to with a traditional GitLab installation, there is no need to change
the user or the
RAILS_ENV environment variable; this is taken care of by the
gitlab-rake wrapper script.
This content has been moved to the GitLab debugging tips documentation.
If you need superuser access to the bundled PostgreSQL service you can
gitlab-psql command. It takes the same arguments as the
# Superuser psql access to GitLab's database sudo gitlab-psql -d gitlabhq_production
This will only work after you have run
gitlab-ctl reconfigure at
least once. The
gitlab-psql command cannot be used to connect to a
remote PostgreSQL server, nor to connect to a local non-Omnibus PostgreSQL
Similar to the previous command, if you need superuser access to the bundled
Geo tracking database (
geo-postgresql), you can use the
It takes the same arguments as the regular
psql command. For HA, see more
about the necessary arguments in:
# Superuser psql access to GitLab's Geo tracking database sudo gitlab-geo-psql -d gitlabhq_geo_production
Container Registry can use considerable amounts of disk space. To clear up unused layers, the registry includes a garbage collect command.