diff options
author | Robert Speicher <robert@gitlab.com> | 2015-12-15 18:36:28 +0000 |
---|---|---|
committer | Robert Speicher <robert@gitlab.com> | 2015-12-15 18:36:28 +0000 |
commit | 28a8d0b5db104be6d01ad647aefcd92ec9ec113e (patch) | |
tree | 670077cb83fd37f0b49bc7b135f1f356a4f46309 /doc | |
parent | 96a1558897c7628f8d49435647f052ec24a63986 (diff) | |
parent | f8bf6c4b2c5fb41ae92df09b9f968d5d5d61bb2b (diff) | |
download | gitlab-ce-28a8d0b5db104be6d01ad647aefcd92ec9ec113e.tar.gz |
Merge branch 'add_user_repo_integrity_rake_task' into 'master'
Add user repository integrity check rake task
Corrupt repositories and stuck lock files can cause weird issues in
GitLab. Often we know which user is having these problems and then we
have to go hunt down which repository is causing it. Several times
recently that involved me running queries in the rails console to get
an array of projects and then writing a quick Ruby script to loop
through and run `git fsck`. This last time I also had to check for the
existence of `config.lock` and ref lock files.
This rake task will eliminate all of those steps and allow an admin to
simply specify a username.
I also added the lock file checks to the existing `gitlab:repo:check`
task which goes through all projects.
See merge request !2080
Diffstat (limited to 'doc')
-rw-r--r-- | doc/raketasks/README.md | 3 | ||||
-rw-r--r-- | doc/raketasks/check.md | 63 | ||||
-rw-r--r-- | doc/raketasks/check_repos_output.png | bin | 0 -> 73786 bytes |
3 files changed, 65 insertions, 1 deletions
diff --git a/doc/raketasks/README.md b/doc/raketasks/README.md index a8dc5c24df2..cc8a22cd003 100644 --- a/doc/raketasks/README.md +++ b/doc/raketasks/README.md @@ -1,10 +1,11 @@ # Rake tasks - [Backup restore](backup_restore.md) +- [Check](check.md) - [Cleanup](cleanup.md) - [Features](features.md) - [Maintenance](maintenance.md) and self-checks - [User management](user_management.md) - [Web hooks](web_hooks.md) - [Import](import.md) of git repositories in bulk -- [Rebuild authorized_keys file](http://doc.gitlab.com/ce/raketasks/maintenance.html#rebuild-authorized_keys-file) task for administrators
\ No newline at end of file +- [Rebuild authorized_keys file](http://doc.gitlab.com/ce/raketasks/maintenance.html#rebuild-authorized_keys-file) task for administrators diff --git a/doc/raketasks/check.md b/doc/raketasks/check.md new file mode 100644 index 00000000000..3ff3fee6a40 --- /dev/null +++ b/doc/raketasks/check.md @@ -0,0 +1,63 @@ +# Check Rake Tasks + +## Repository Integrity + +Even though Git is very resilient and tries to prevent data integrity issues, +there are times when things go wrong. The following Rake tasks intend to +help GitLab administrators diagnose problem repositories so they can be fixed. + +There are 3 things that are checked to determine integrity. + +1. Git repository file system check ([git fsck](https://git-scm.com/docs/git-fsck)). + This step verifies the connectivity and validity of objects in the repository. +1. Check for `config.lock` in the repository directory. +1. Check for any branch/references lock files in `refs/heads`. + +It's important to note that the existence of `config.lock` or reference locks +alone do not necessarily indicate a problem. Lock files are routinely created +and removed as Git and GitLab perform operations on the repository. They serve +to prevent data integrity issues. However, if a Git operation is interrupted these +locks may not be cleaned up properly. + +The following symptoms may indicate a problem with repository integrity. If users +experience these symptoms you may use the rake tasks described below to determine +exactly which repositories are causing the trouble. + +- Receiving an error when trying to push code - `remote: error: cannot lock ref` +- A 500 error when viewing the GitLab dashboard or when accessing a specific project. + +### Check all GitLab repositories + +This task loops through all repositories on the GitLab server and runs the +3 integrity checks described previously. + +``` +# omnibus-gitlab +sudo gitlab-rake gitlab:repo:check + +# installation from source +bundle exec rake gitlab:repo:check RAILS_ENV=production +``` + +### Check repositories for a specific user + +This task checks all repositories that a specific user has access to. This is important +because sometimes you know which user is experiencing trouble but you don't know +which project might be the cause. + +If the rake task is executed without brackets at the end, you will be prompted +to enter a username. + +```bash +# omnibus-gitlab +sudo gitlab-rake gitlab:user:check_repos +sudo gitlab-rake gitlab:user:check_repos[<username>] + +# installation from source +bundle exec rake gitlab:user:check_repos RAILS_ENV=production +bundle exec rake gitlab:user:check_repos[<username>] RAILS_ENV=production +``` + +Example output: + + diff --git a/doc/raketasks/check_repos_output.png b/doc/raketasks/check_repos_output.png Binary files differnew file mode 100644 index 00000000000..916b1685101 --- /dev/null +++ b/doc/raketasks/check_repos_output.png |