gitlab

Create a new project

$ gitlab create_project [project_name]

$ gitlab commit [project_name] [commit_hash]

$ gitlab pipeline_jobs [project_name] [pipeline_id]

$ gitlab job_play [project_name] [job_id]

gitlab-ctl command [options]

reconfigure
    Reapplies and reloads the GitLab configuration based on /etc/gitlab/gitlab.rb.

start
    Starts all GitLab services.

stop
    Stops all GitLab services.

restart
    Restarts all GitLab services.

status
    Displays the current operational status of all GitLab services.

tail service
    Follows the real-time logs of a specific GitLab service (e.g., nginx, unicorn, sidekiq).

console
    Opens an interactive GitLab Rails console for advanced administration and debugging.

rake task
    Executes a GitLab Rake task (e.g., gitlab-ctl rake gitlab:check for system diagnostics).

hup
    Sends a HUP signal to relevant services, often used for non-disruptive configuration reloads.

service-list
    Lists all services managed by the GitLab Omnibus package.

clean-logs
    Cleans up old application and service logs to free disk space.

backup-etc
    Creates a tarball backup of the /etc/gitlab directory, including gitlab.rb and SSL certificates.

The gitlab-ctl command is the primary administrative utility for managing a GitLab Omnibus installation. It provides a comprehensive set of tools to control the lifecycle and configuration of various GitLab components, including Nginx, PostgreSQL, Redis, Unicorn, Sidekiq, and Prometheus.

It significantly simplifies the administration of a complex GitLab setup by offering commands to start, stop, restart, reconfigure, and check the health of these bundled services. This command is indispensable for performing routine maintenance, applying configuration changes defined in /etc/gitlab/gitlab.rb, and troubleshooting operational issues within the GitLab environment.

Most gitlab-ctl operations require root privileges (i.e., running with sudo).
This utility is designed specifically for GitLab Omnibus installations and is not applicable to source installations or containerized deployments (like Docker or Kubernetes).
Using the console or rake subcommands without proper knowledge can lead to data corruption or service outages. Always consult GitLab documentation before executing complex tasks.

All primary configuration for the GitLab Omnibus installation is managed via the /etc/gitlab/gitlab.rb file. After making any changes to this file, you must run gitlab-ctl reconfigure for the changes to take effect.

GitLab service logs are typically stored under /var/log/gitlab/. Each service has its own subdirectory within this path (e.g., /var/log/gitlab/nginx/, /var/log/gitlab/unicorn/). The gitlab-ctl tail command is a convenient way to view these logs in real-time.

For initial troubleshooting, start with gitlab-ctl status to check which services are running or failing.
Reviewing logs with gitlab-ctl tail is crucial for identifying error messages.
If configuration issues are suspected, running gitlab-ctl reconfigure can often resolve inconsistencies, and gitlab-ctl check-config (if available in your GitLab version) can validate the gitlab.rb syntax.

The gitlab-ctl command emerged as a core component of the GitLab Omnibus package, which was first introduced to drastically simplify the installation and management of GitLab. Prior to Omnibus, deploying GitLab involved manually configuring numerous interdependent services (Ruby on Rails application, Nginx, PostgreSQL, Redis, Sidekiq, etc.), a process that was notoriously complex and prone to errors.

By bundling all necessary dependencies and providing gitlab-ctl as a unified command-line interface, GitLab greatly streamlined deployments and ongoing maintenance for system administrators. It leverages an embedded Chef client for robust configuration management, allowing administrators to define their GitLab instance's settings in a single gitlab.rb file and apply them reliably.

gitlab-rake(8), gitlab-rails(8), systemctl(1), nginx(8), postgresql(1)