debian-mirror-gitlab/doc/administration/restart_gitlab.md

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

131 lines
4 KiB
Markdown
Raw Normal View History

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