2020-10-23 20:08:35 -04:00
---
2022-05-29 20:08:35 -04:00
stage: Systems
2020-12-01 13:09:42 -05:00
group: Distribution
2022-09-21 17:13:33 -04:00
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
2020-10-23 20:08:35 -04:00
---
2021-04-19 14:09:09 -04:00
# How to restart GitLab **(FREE SELF)**
2016-01-20 04:33:59 -05:00
Depending on how you installed GitLab, there are different methods to restart
2022-02-11 13:18:58 -05:00
its services.
2016-01-20 04:33:59 -05:00
2022-03-04 04:16:29 -05:00
NOTE:
A short downtime is expected for all methods.
2016-01-20 04:33:59 -05:00
## Omnibus installations
2020-04-21 11:21:10 -04:00
If you have used the [Omnibus packages ](https://about.gitlab.com/install/ ) to install GitLab, then
2016-01-21 13:57:41 -05:00
you should already have `gitlab-ctl` in your `PATH` .
2016-01-20 04:33:59 -05:00
`gitlab-ctl` interacts with the Omnibus packages and can be used to restart the
2020-05-14 05:07:53 -04:00
GitLab Rails application (Puma) as well as the other components, like:
2016-01-20 04:33:59 -05:00
- GitLab Workhorse
- Sidekiq
- PostgreSQL (if you are using the bundled one)
- NGINX (if you are using the bundled one)
- Redis (if you are using the bundled one)
2020-04-21 11:21:10 -04:00
- [Mailroom ](reply_by_email.md )
2016-01-21 13:57:41 -05:00
- Logrotate
2016-01-20 04:33:59 -05:00
### Omnibus GitLab restart
2021-04-25 17:09:26 -04:00
There may be times in the documentation where you are asked to _restart_
2022-07-15 08:10:10 -04:00
GitLab. To restart, run the following command:
2016-01-20 04:33:59 -05:00
2020-01-30 10:09:15 -05:00
```shell
2016-01-20 04:33:59 -05:00
sudo gitlab-ctl restart
```
The output should be similar to this:
2020-03-23 23:09:28 -04:00
```plaintext
2016-01-20 04:33:59 -05:00
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
2020-05-14 05:07:53 -04:00
ok: run: puma: (pid 11338) 0s
2016-01-20 04:33:59 -05:00
```
To restart a component separately, you can append its service name to the
`restart` command. For example, to restart **only** NGINX you would run:
2020-01-30 10:09:15 -05:00
```shell
2016-01-20 04:33:59 -05:00
sudo gitlab-ctl restart nginx
```
To check the status of GitLab services, run:
2020-01-30 10:09:15 -05:00
```shell
2016-01-20 04:33:59 -05:00
sudo gitlab-ctl status
```
2016-01-21 13:57:41 -05:00
Notice that all services say `ok: run` .
2019-02-11 05:44:39 -05:00
Sometimes, components time out (look for `timeout` in the logs) during the
restart and sometimes they get stuck.
2016-01-21 13:57:41 -05:00
In that case, you can use `gitlab-ctl kill <service>` to send the `SIGKILL`
signal to the service, for example `sidekiq` . After that, a restart should
perform fine.
As a last resort, you can try to
2016-01-20 04:33:59 -05:00
[reconfigure GitLab ](#omnibus-gitlab-reconfigure ) instead.
### Omnibus GitLab reconfigure
2021-04-25 17:09:26 -04:00
There may be times in the documentation where you are asked to _reconfigure_
2016-01-21 13:57:41 -05:00
GitLab. Remember that this method applies only for the Omnibus packages.
2016-01-20 04:33:59 -05:00
Reconfigure Omnibus GitLab with:
2020-01-30 10:09:15 -05:00
```shell
2016-01-20 04:33:59 -05:00
sudo gitlab-ctl reconfigure
```
Reconfiguring GitLab should occur in the event that something in its
configuration (`/etc/gitlab/gitlab.rb`) has changed.
2021-07-02 14:08:28 -04:00
When you run this command, [Chef ](https://www.chef.io/products/chef-infra ), the underlying configuration management
2021-04-25 17:09:26 -04:00
application that powers Omnibus GitLab, makes sure that all things like directories,
2020-02-21 01:08:58 -05:00
permissions, and services are in place and in the same shape that they were
2016-01-21 13:57:41 -05:00
initially shipped.
2022-03-04 04:16:29 -05:00
It also [restarts GitLab components ](#how-to-restart-gitlab )
where needed, if any of their configuration files have changed.
2016-01-21 13:57:41 -05:00
If you manually edit any files in `/var/opt/gitlab` that are managed by Chef,
2022-06-06 14:09:02 -04:00
running reconfigure reverts the changes and restarts the services that
2016-01-21 13:57:41 -05:00
depend on those files.
2016-01-20 04:33:59 -05:00
## Installations from source
2022-08-23 20:12:25 -04:00
If you have followed the official installation guide to
2022-08-07 23:09:21 -04:00
[install GitLab from source ](../install/installation.md ), run the following command to restart GitLab:
2016-01-20 04:33:59 -05:00
2020-03-23 23:09:28 -04:00
```shell
2021-10-28 11:09:42 -04:00
# For systems running systemd
sudo systemctl restart gitlab.target
2016-01-20 04:33:59 -05:00
2021-10-28 11:09:42 -04:00
# For systems running SysV init
sudo service gitlab restart
2016-01-20 04:33:59 -05:00
```
2020-05-14 05:07:53 -04:00
This should restart Puma, Sidekiq, GitLab Workhorse, and [Mailroom ](reply_by_email.md )
2021-10-28 11:09:42 -04:00
(if enabled).
2016-01-20 04:33:59 -05:00
2019-12-06 13:07:44 -05:00
## Helm chart installations
There is no single command to restart the entire GitLab application installed via
2022-09-29 05:09:45 -04:00
the [cloud-native Helm chart ](https://docs.gitlab.com/charts/ ). Usually, it should be
2020-05-14 05:07:53 -04:00
enough to restart a specific component separately (for example, `gitaly` , `puma` ,
2020-02-21 01:08:58 -05:00
`workhorse` , or `gitlab-shell` ) by deleting all the pods related to it:
2019-12-06 13:07:44 -05:00
2020-01-30 10:09:15 -05:00
```shell
2019-12-06 13:07:44 -05:00
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.