- Gather GitLab and system information
- Show GitLab license information
- Check GitLab configuration
- Clear Redis cache
- Precompile the assets
- Check TCP connectivity to a remote site
- Clear exclusive lease (DANGER)
- Display status of database migrations
- Run incomplete database migrations
- Rebuild database indexes
- Import common metrics
GitLab provides Rake tasks for general maintenance.
This command gathers information about your GitLab installation and the system it runs on. These may be useful when asking for help or reporting issues.
sudo gitlab-rake gitlab:env:info
bundle exec rake gitlab:env:info RAILS_ENV=production
System information System: Ubuntu 20.04 Proxy: no Current User: git Using RVM: no Ruby Version: 2.6.6p146 Gem Version: 2.7.10 Bundler Version:1.17.3 Rake Version: 12.3.3 Redis Version: 5.0.9 Git Version: 2.27.0 Sidekiq Version:5.2.9 Go Version: unknown GitLab information Version: 13.2.2-ee Revision: 618883a1f9d Directory: /opt/gitlab/embedded/service/gitlab-rails DB Adapter: PostgreSQL DB Version: 11.7 URL: http://gitlab.example.com HTTP Clone URL: http://gitlab.example.com/some-group/some-project.git SSH Clone URL: email@example.com:some-group/some-project.git Elasticsearch: no Geo: no Using LDAP: no Using Omniauth: yes Omniauth Providers: GitLab Shell Version: 13.3.0 Repository storage paths: - default: /var/opt/gitlab/git-data/repositories GitLab Shell path: /opt/gitlab/embedded/service/gitlab-shell
- Introduced in GitLab 12.6.
- Moved to GitLab Premium in 13.9.
This command shows information about your GitLab license and how many seats are used. It is only available on GitLab Enterprise installations: a license cannot be installed into GitLab Community Edition.
These may be useful when raising tickets with Support, or for programmatically checking your license parameters.
sudo gitlab-rake gitlab:license:info
bundle exec rake gitlab:license:info RAILS_ENV=production
Today's Date: 2020-02-29 Current User Count: 30 Max Historical Count: 30 Max Users in License: 40 License valid from: 2019-11-29 to 2020-11-28 Email associated with license: firstname.lastname@example.org
gitlab:check Rake task runs the following Rake tasks:
It checks that each component was set up according to the installation guide and suggest fixes for issues found. This command must be run from your application server and doesn’t work correctly on component servers like Gitaly. If you’re running Geo, see also the Geo Health check Rake task.
You may also have a look at our troubleshooting guides for:
Additionally you should also verify database values can be decrypted using the current secrets.
sudo gitlab-rake gitlab:check
bundle exec rake gitlab:check RAILS_ENV=production
gitlab:check if you want to omit project names from the output.
Checking Environment ... Git configured for git user? ... yes Has python2? ... yes python2 is supported version? ... yes Checking Environment ... Finished Checking GitLab Shell ... GitLab Shell version? ... OK (1.2.0) Repo base directory exists? ... yes Repo base directory is a symlink? ... no Repo base owned by git:git? ... yes Repo base access is drwxrws---? ... yes post-receive hook up-to-date? ... yes post-receive hooks in repos are links: ... yes Checking GitLab Shell ... Finished Checking Sidekiq ... Running? ... yes Checking Sidekiq ... Finished Checking GitLab ... Database config exists? ... yes Database is SQLite ... no All migrations up? ... yes GitLab config exists? ... yes GitLab config outdated? ... no Log directory writable? ... yes Tmp directory writable? ... yes Init script exists? ... yes Init script up-to-date? ... yes Redis version >= 2.0.0? ... yes Checking GitLab ... Finished
In some cases it is necessary to rebuild the
for example, if after an upgrade you receive
Permission denied (publickey) when pushing via SSH
404 Key Not Found errors in the
sudo gitlab-rake gitlab:shell:setup
cd /home/git/gitlab sudo -u git -H bundle exec rake gitlab:shell:setup RAILS_ENV=production
This will rebuild an authorized_keys file. You will lose any data stored in authorized_keys file. Do you want to continue (yes/no)? yes
If for some reason the dashboard displays the wrong information, you might want to clear Redis’ cache. To do this, run:
sudo gitlab-rake cache:clear
cd /home/git/gitlab sudo -u git -H bundle exec rake cache:clear RAILS_ENV=production
Sometimes during version upgrades you might end up with some wrong CSS or missing some icons. In that case, try to precompile the assets again.
This only applies to source installations and does NOT apply to Omnibus packages.
cd /home/git/gitlab sudo -u git -H bundle exec rake gitlab:assets:compile RAILS_ENV=production
the release of upstream GitLab. The omnibus version includes optimized versions
production machine after installing the package, there should be no reason to redo
rake gitlab:assets:compile on the production machine. If you suspect that assets
have been corrupted, you should reinstall the omnibus package.
Sometimes you need to know if your GitLab installation can connect to a TCP service on another machine (for example a PostgreSQL or web server) to troubleshoot proxy issues. A Rake task is included to help you with this.
sudo gitlab-rake gitlab:tcp_check[example.com,80]
cd /home/git/gitlab sudo -u git -H bundle exec rake gitlab:tcp_check[example.com,80] RAILS_ENV=production
GitLab uses a shared lock mechanism:
ExclusiveLease to prevent simultaneous operations
in a shared resource. An example is running periodic garbage collection on repositories.
In very specific situations, an operation locked by an Exclusive Lease can fail without releasing the lock. If you can’t wait for it to expire, you can run this task to manually clear it.
To clear all exclusive leases:
sudo gitlab-rake gitlab:exclusive_lease:clear
To specify a lease
type or lease
type + id, specify a scope:
# to clear all leases for repository garbage collection: sudo gitlab-rake gitlab:exclusive_lease:clear[project_housekeeping:*] # to clear a lease for repository garbage collection in a specific project: (id=4) sudo gitlab-rake gitlab:exclusive_lease:clear[project_housekeeping:4]
See the upgrade documentation for how to check that migrations are complete when upgrading GitLab.
To check the status of specific migrations, you can use the following Rake task:
sudo gitlab-rake db:migrate:status
This outputs a table with a
each Migration ID.
database: gitlabhq_production Status Migration ID Migration Name -------------------------------------------------- up migration_id migration_name
Database migrations can be stuck in an incomplete state, with a
status in the output of the
sudo gitlab-rake db:migrate:status command.
To complete these migrations, use the following Rake task:
sudo gitlab-rake db:migrate
After the command completes, run
sudo gitlab-rake db:migrate:status to check if all
migrations are completed (have an
Database indexes can be rebuilt regularly to reclaim space and maintain healthy levels of index bloat over time.
To rebuild the two indexes with the highest estimated bloat, use the following Rake task:
sudo gitlab-rake gitlab:db:reindex
To target a specific index, use the following Rake task:
sudo gitlab-rake gitlab:db:reindex['public.a_specific_index']
The following index types are not supported:
- Indexes used for constraint exclusion
- Partitioned indexes
- Expression indexes
Optionally, this Rake task sends annotations to a Grafana (4.6 or later) endpoint. Use the following custom environment variables to enable annotations:
GRAFANA_API_URL- Grafana’s base URL, for example
GRAFANA_API_KEY- Grafana API key with at least
You can also enable reindexing as a regular cron job.
Sometimes you may need to re-import the common metrics that power the Metrics dashboards.
To re-import the metrics you can run:
sudo gitlab-rake metrics:setup_common_metrics