LinuxCommandLibrary

gitlab-ctl

Manage and control GitLab services

TLDR

Display the status of every service

$ sudo gitlab-ctl status
copy

Display the status of a specific service
$ sudo gitlab-ctl status [nginx]
copy

Restart every service
$ sudo gitlab-ctl restart
copy

Restart a specific service
$ sudo gitlab-ctl restart [nginx]
copy

Display the logs of every service and keep reading until is pressed
$ sudo gitlab-ctl tail
copy

Display the logs of a specific service
$ sudo gitlab-ctl tail [nginx]
copy

Send the SIGKILL signal to specific service
$ sudo gitlab-ctl kill [nginx]
copy

Reconfigure the application
$ sudo gitlab-ctl reconfigure
copy

SYNOPSIS

gitlab-ctl [options] command [arguments]

PARAMETERS

-h, --help
    Display help for gitlab-ctl or a specific subcommand

--version
    Output the gitlab-ctl version

--log-level LEVEL
    Set log verbosity (debug, info, warn, error, fatal)

reconfigure
    Reconfigure GitLab: compile config, notify services, restart as needed

reconfigure-now
    Reconfigure without saving a checkpoint

start [SERVICE]
    Start all GitLab services or a specific one (e.g., postgresql)

stop [SERVICE]
    Gracefully stop all services or a specific one

restart [SERVICE]
    Restart all services or a specific one

status
    Show run status of all GitLab services

tail [SERVICE]
    Tail logs for all services or a specific one

show-config
    Display the runtime configuration as Ruby

ps
    List processes for all services

invoke SERVICE COMMAND [ARGS]
    Run a command in the context of a service (e.g., rails console)

DESCRIPTION

gitlab-ctl is the primary command-line interface for managing GitLab installations delivered via the Omnibus package on Linux systems.

It provides a unified way to control all embedded services, including the Nginx web server, PostgreSQL database, Redis cache, Sidekiq background jobs, Gitaly Git service, and more.

Key functions include starting, stopping, restarting, and monitoring service status; tailing logs; and applying configuration changes through Chef Solo recipes. The flagship reconfigure subcommand regenerates configuration files from /etc/gitlab/gitlab.rb, compiles them, and restarts affected services.

Designed for production environments, it ensures atomic updates and idempotent operations. Use it to troubleshoot issues, perform maintenance, or scale deployments. Always run with elevated privileges (sudo).

For source installations, use standard service managers like systemd instead.

CAVEATS

Requires GitLab Omnibus package; not for source installs.
Run as root/sudo. Some subcommands like reconfigure can take 5-10 minutes.
Services must match enabled components in gitlab.rb.

SERVICE NAMES

Common services: gitaly, gitlab-workhorse, nginx, postgresql, redis, puma, sidekiq.
Use gitlab-ctl status to list.

CONFIG FILE

Edit /etc/gitlab/gitlab.rb, then run gitlab-ctl reconfigure.

HISTORY

Introduced in GitLab Omnibus 8.0 (2014) using Chef for config management.
Evolved with GitLab releases; now supports containerized services in 15.0+.

SEE ALSO

systemctl(1), service(8), chef-client(8)

Copied to clipboard