문제 해결

Tier: Free, Premium, Ultimate Offering: Self-managed

GitLab 설치 상태 가져오기 

sudo gitlab-ctl status
sudo gitlab-rake gitlab:check SANITIZE=true

RPM ‘package is already installed’ 오류

RPM을 사용하고 GitLab Community Edition에서 GitLab Enterprise Edition으로 업그레이드하는 경우 다음과 같은 오류가 발생할 수 있습니다: 

package gitlab-7.5.2_omnibus.5.2.1.ci-1.el7.x86_64 (which is newer than gitlab-7.5.2_ee.omnibus.5.2.1.ci-1.el7.x86_64) is already installed

--oldpackage 옵션으로 이 버전 확인을 재정의할 수 있습니다: 

sudo rpm -Uvh --oldpackage gitlab-7.5.2_ee.omnibus.5.2.1.ci-1.el7.x86_64.rpm

설치된 패키지에 의해 더 이상 사용되지 않는 패키지 오류

CE 및 EE 패키지는 서로를 사용하지 않도록 표시되어 있어 동시에 설치 및 실행되지 않습니다.

CE에서 EE로 또는 그 반대로 전환하려면 로컬 RPM 파일을 사용하여 패키지를 설치할 때 yum 대신 rpm을 사용하세요. yum을 사용하려고 하면 다음과 같은 오류가 발생할 수 있습니다: 

Cannot install package gitlab-ee-11.8.3-ee.0.el6.x86_64. It is obsoleted by installed package gitlab-ce-11.8.3-ce.0.el6.x86_64

이 문제를 피하려면 다음 중 하나를 수행하세요:

프로젝트 > 설정 > 저장소에 액세스할 때 500 오류

GitLab이 CE > EE > CE로 전환되고 다시 EE로 전환될 때이 오류가 발생합니다. 프로젝트의 저장소 설정을 보는 경우 다음과 같은 오류가 로그에 표시됩니다: 

Processing by Projects::Settings::RepositoryController#show as HTML
  Parameters: {"namespace_id"=>"<namespace_id>", "project_id"=>"<project_id>"}
Completed 500 Internal Server Error in 62ms (ActiveRecord: 4.7ms | Elasticsearch: 0.0ms | Allocations: 14583)

NoMethodError (undefined method `commit_message_negative_regex' for #<PushRule:0x00007fbddf4229b8>
Did you mean?  commit_message_regex_change):

이 오류는 초기 EE로 이동할 때 CE 인스턴스에 EE 기능이 추가되어 발생합니다. 인스턴스가 다시 CE로 이동한 후 EE로 다시 업그레이드되면 push_rules 테이블이 이미 데이터베이스에 존재합니다. 따라서 마이그레이션은 commit_message_regex_change 열을 추가할 수 없습니다.

이로 인해 EE 테이블의 백포트 마이그레이션이 올바르게 작동하지 않습니다. 백포트 마이그레이션은 CE에서 실행되는 동안 데이터베이스의 특정 테이블이 존재하지 않는 것을 가정합니다.

이 문제를 해결하려면 다음을 수행하세요:

  1. 데이터베이스 콘솔을 시작합니다: 

    sudo gitlab-rails dbconsole --database main

  2. 누락 된 commit_message_negative_regex 열을 수동으로 추가합니다: 

    ALTER TABLE push_rules ADD COLUMN commit_message_negative_regex VARCHAR;

# psql 종료
\q

  3. GitLab을 다시 시작합니다: 

    sudo gitlab-ctl restart

로그에 PG::UndefinedColumn: ERROR:.. 메시지와 함께 500 오류가 발생하는 경우

업그레이드 후 로그에서 PG::UndefinedColumn: ERROR:...과 유사한 메시지가 표시되면 이러한 오류는 다음 중 하나에 의해 발생할 수 있습니다:

  • 데이터베이스 마이그레이션이 아직 완료되지 않았습니다. 마이그레이션이 완료 될 때까지 기다립니다.
  • 데이터베이스 마이그레이션이 완료되었지만 GitLab이 새로운 스키마를로드해야하는 경우. 새로운 스키마를로드하려면 GitLab을 다시 시작하십시오.

오류: 내부 GitLab API에 연결하지 못했습니다

분리된 GitLab Pages 서버에서 내부 GitLab API에 연결하지 못했습니다 오류가 발생하는 경우, GitLab Pages 관리 문제 해결을 참조하십시오.

서명 검증 중 오류 발생

apt-get update를 실행할 때이 오류가 발생하는 경우: 

서명 검증 중 오류가 발생했습니다

다음 명령을 사용하여 GitLab 패키지 서버의 GPG 키를 업데이트하십시오: 

curl --silent "https://packages.gitlab.com/gpg.key" | apt-key add -
apt-get update

Mixlib::ShellOut::CommandTimeout: rails_migration[gitlab-rails] [..] 오류

데이터베이스 스키마 및 데이터 변경 (데이터베이스 마이그레이션)이 1시간 이상 걸리면 업그레이드가 시간 초과 오류로 실패합니다: 

FATAL: Mixlib::ShellOut::CommandTimeout: rails_migration[gitlab-rails] (gitlab::database_migrations line 51)
had an error: Mixlib::ShellOut::CommandTimeout: bash[migrate gitlab-rails database]
(/opt/gitlab/embedded/cookbooks/cache/cookbooks/gitlab/resources/rails_migration.rb line 16)
had an error: Mixlib::ShellOut::CommandTimeout: Command timed out after 3600s:

이 오류를 해결하려면:

  1. 남은 데이터베이스 마이그레이션을 실행합니다: 

    sudo gitlab-rake db:migrate

    이 명령은 매우 긴 시간이 걸릴 수 있습니다. SSH 세션이 끊기는 경우를 대비하여 screen 또는 다른 메커니즘을 사용하여 프로그램이 중단되지 않도록합니다.

  2. 업그레이드를 완료합니다: 

    sudo gitlab-ctl reconfigure

  3. puma 및 sidekiq 서비스를 핫 리로드합니다: 

    sudo gitlab-ctl hup puma
sudo gitlab-ctl restart sidekiq

누락된 에셋 파일

업그레이드 이후, GitLab은 이미지, JavaScript 및 스타일 시트와 같은 에셋을 올바르게 제공하지 못할 수 있습니다. 500 에러가 발생하거나, 웹 UI가 올바르게 렌더링되지 않을 수 있습니다.

로드 밸런서 뒤의 여러 웹 서버를 가진 GitLab 환경에서, 한 대의 웹 서버에서 이 문제가 발견되면, 문제는 때때로 발생합니다.

에셋을 다시 컴파일하는 레일스 작업은 /opt/gitlab/embedded/service/gitlab-rails/public/assets에서 사전 컴파일된 에셋을 제공하는 Omnibus 설치에는 적용되지 않습니다.

가능한 원인과 해결책:

ActiveRecord::LockWaitTimeout 에러, 일정 시간 후 재시도

드물게, Sidekiq이 바쁘게 움직이고 있는 상황에서 마이그레이션을 수정하려는 테이블을 잠근 상태일 수 있습니다. 이 문제를 해결하기 위해 GitLab을 읽기 전용 모드로 전환하고 Sidekiq을 중지해야 합니다. 

gitlab-ctl stop sidekiq

이전 프로세스

가장 가능성이 높은 원인은 이전 버전의 GitLab에서 클라이언트에게 에셋 파일을 요청하도록 지시하는 이전 Puma 프로세스가 실행 중인 것입니다. 파일이 더 이상 존재하지 않기 때문에, HTTP 404 에러가 반환됩니다.

이러한 이전 Puma 프로세스가 더 이상 실행되지 않도록 하려면, 시스템을 다시 부팅하는 것이 가장 좋은 방법입니다.

대안으로:

  1. Puma 중지: 

    gitlab-ctl stop puma

  2. 잔존하는 Puma 프로세스를 확인하고, 종료합니다: 

    ps -ef | egrep 'puma[: ]'
kill <processid>

  3. ps로 Puma 프로세스가 중지되었는지 확인합니다.

  4. Puma 시작: 

    gitlab-ctl start puma

중복된 스프로켓 파일

컴파일된 에셋 파일에는 각 릴리스마다 고유한 파일 이름이 있습니다. 스프로켓 파일들은 응용 프로그램 코드에서 고유한 파일 이름으로부터 릴리스별 고유한 파일 이름으로 매핑을 제공합니다. 

/opt/gitlab/embedded/service/gitlab-rails/public/assets/.sprockets-manifest*.json

하나의 스프로켓 파일만 있는지 확인해 주세요. 레일스는 첫 번째 파일을 사용합니다.

Omnibus GitLab 업그레이드 중에 중복된 스프로켓 파일을 확인하는 체크가 실행됩니다: 

이전 설치에서 크기가 큰 파일을 발견했습니다. 정리해야 할 파일 목록:

/opt/gitlab/embedded/service/gitlab-rails/public/assets/.sprockets-manifest-e16fdb7dd73cfdd64ed9c2cc0e35718a.json

이를 해결하기 위한 옵션은 다음과 같습니다:

  • 패키지 업그레이드의 출력이 있다면, 지정된 파일을 제거한 후 Puma를 재시작하세요: 

    gitlab-ctl restart puma
  • 메시지가 없는 경우, 다시 설치하여 다시 생성하십시오 (자세한 내용은 설치 불완전 참조)
  • 모든 스프로켓 파일을 제거한 다음 설치 불완전의 지침을 따르세요.

설치 불완전

불완전한 설치가 이 문제의 원인일 수 있습니다.

이 문제가 문제인지 확인하려면, 패키지를 확인하세요:

  • Debian 배포판의 경우: 

    apt-get install debsums
debsums -c gitlab-ee

  • Red Hat/SUSE (RPM) 배포판의 경우: 

    rpm -V gitlab-ee

불완전한 설치를 해결하기 위해 패키지를 재설치하려면:

  1. 설치된 버전 확인

    • Debian 배포판의 경우: 

      apt --installed list gitlab-ee

    • Red Hat/SUSE (RPM) 배포판의 경우: 

      rpm -qa gitlab-ee

  2. 설치된 버전을 지정하여 패키지를 재설치하십시오. 예를 들어 Enterprise Edition 14.4.0의 경우:

    • Debian 배포판의 경우: 

      apt-get install --reinstall gitlab-ee=14.4.0-ee.0

    • Red Hat/SUSE (RPM) 배포판의 경우: 

      yum reinstall gitlab-ee-14.4.0

NGINX Gzip 지원

nginx['gzip_enabled']가 비활성화되었는지 확인하세요: 

grep gzip /etc/gitlab/gitlab.rb

이는 일부 에셋의 제공을 방해할 수 있습니다. 관련된 이슈 중 하나에서 자세히 보기.