- Omnibus installations
- Installations from source
- Helm chart installations
- Docker installation
How to restart GitLab
Depending on how you installed GitLab, there are different methods to restart its services.
If you have used the Omnibus packages to install GitLab,
you should already have
gitlab-ctl in your
gitlab-ctl interacts with the Omnibus packages and can be used to restart the
GitLab Rails application (Puma) as well as the other components, like:
- GitLab Workhorse
- PostgreSQL (if you are using the bundled one)
- NGINX (if you are using the bundled one)
- Redis (if you are using the bundled one)
Omnibus GitLab restart
There may be times in the documentation where you are asked to restart GitLab. To restart, run the following command:
sudo gitlab-ctl restart
The output should be similar to this:
ok: run: gitlab-workhorse: (pid 11291) 1s ok: run: logrotate: (pid 11299) 0s ok: run: mailroom: (pid 11306) 0s ok: run: nginx: (pid 11309) 0s ok: run: postgresql: (pid 11316) 1s ok: run: redis: (pid 11325) 0s ok: run: sidekiq: (pid 11331) 1s ok: run: puma: (pid 11338) 0s
To restart a component separately, you can append its service name to the
restart command. For example, to restart only NGINX you would run:
sudo gitlab-ctl restart nginx
To check the status of GitLab services, run:
sudo gitlab-ctl status
Notice that all services say
Sometimes, components time out (look for
timeout in the logs) during the
restart and sometimes they get stuck.
In that case, you can use
gitlab-ctl kill <service> to send the
signal to the service, for example
sidekiq. After that, a restart should
As a last resort, you can try to reconfigure GitLab instead.
Omnibus GitLab reconfigure
There may be times in the documentation where you are asked to reconfigure GitLab. Remember that this method applies only for the Omnibus packages.
Reconfigure Omnibus GitLab with:
sudo gitlab-ctl reconfigure
Reconfiguring GitLab should occur in the event that something in its
/etc/gitlab/gitlab.rb) has changed.
When you run
gitlab-ctl reconfigure, Chef,
the underlying configuration management application that powers Omnibus GitLab, runs some checks.
Chef ensures directories, permissions, and services are in place and working.
Chef also restarts GitLab components if any of their configuration files have changed.
If you manually edit any files in
/var/opt/gitlab that are managed by Chef,
reconfigure reverts the changes and restarts the services that
depend on those files.
Installations from source
If you have followed the official installation guide to install GitLab from source, run the following command to restart GitLab:
# For systems running systemd sudo systemctl restart gitlab.target # For systems running SysV init sudo service gitlab restart
This should restart Puma, Sidekiq, GitLab Workhorse, and Mailroom (if enabled).
Helm chart installations
There is no single command to restart the entire GitLab application installed through
the cloud-native Helm chart. Usually, it should be
enough to restart a specific component separately (for example,
gitlab-shell) by deleting all the pods related to it:
kubectl delete pods -l release=<helm release name>,app=<component name>
The release name can be obtained from the output of the
helm list command.
If you change the configuration on your Docker installation, for that change to take effect you must restart:
- The main
- Any separate component containers.
For example, if you deployed Sidekiq on a separate container, to restart the containers, run:
sudo docker restart gitlab sudo docker restart sidekiq