Gitaly 문제 해결

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

Gitaly 문제를 해결할 때 아래 정보를 참조하세요. Gitaly Cluster(Praefect) 문제 해결에 대한 정보는
Gitaly Cluster 문제 해결을 참조하세요.

다음 섹션에서는 Gitaly 오류에 대한 가능한 해결책을 제공합니다.

또한 Gitaly 타임아웃 설정과
gitaly/current 파일을 파싱하는 방법에 대한 조언도 확인하세요.

독립 Gitaly 서버 사용 시 버전 확인

독립 Gitaly 서버를 사용할 때는 GitLab과 동일한 버전인지 확인하여
완전한 호환성을 보장해야 합니다:

  1. 왼쪽 사이드바 하단에서 Admin을 선택합니다.
  2. Overview > Gitaly servers를 선택합니다.
  3. 모든 Gitaly 서버가 최신 상태인지 확인합니다.

스토리지 리소스 세부정보 찾기

다음 명령어를 Rails 콘솔에서 실행하여
Gitaly 스토리지의 사용 가능 및 사용 공간을 확인할 수 있습니다:

Gitlab::GitalyClient::ServerService.new("default").storage_disk_statistics
# Gitaly Cluster의 경우
Gitlab::GitalyClient::ServerService.new("<storage name>").disk_statistics

gitaly-debug 사용

gitaly-debug 명령은 Gitaly 및 Git 성능을 위한 “프로덕션 디버깅” 도구를 제공합니다.
이는 프로덕션 엔지니어와 지원 엔지니어가 Gitaly 성능 문제를 조사하는 데 도움을 주기 위해 설계되었습니다.

지원되는 하위 명령어 목록을 보려면 gitaly-debug의 도움말 페이지를 실행하세요:

gitaly-debug -h

문제 해결 시 Git이 필요할 때 gitaly git 사용

디버깅 또는 테스트 목적으로 Gitaly와 동일한 Git 실행 환경을 사용하여 Git 명령을 실행하려면
gitaly git를 사용하세요. gitaly git는 버전 호환성을 보장하기 위한 기본 방법입니다.

gitaly git는 모든 인수를 기본 Git 호출로 전달하며
Git이 지원하는 모든 형태의 입력을 지원합니다. gitaly git를 사용하려면 다음을 실행하세요:

sudo -u git -- /opt/gitlab/embedded/bin/gitaly git <git-command>

예를 들어, 리포지토리의 작업 디렉토리에서 Gitaly를 통해 git ls-tree를 실행하려면:

sudo -u git -- /opt/gitlab/embedded/bin/gitaly git ls-tree --name-status HEAD

커밋, 푸시 및 클론이 401을 반환 

remote: GitLab: 401 Unauthorized

gitlab-secrets.json 파일을 GitLab 애플리케이션 노드와 동기화해야 합니다.

리포지토리 페이지에서 500 및 폴더 콘텐츠 가져오기 오류

Fetching folder content 및 일부 경우 500 오류는 GitLab과 Gitaly 간의 연결 문제를 나타냅니다.
상세 정보를 보려면 클라이언트 측 gRPC 로그를 참조하세요.

클라이언트 측 gRPC 로그

Gitaly는 gRPC RPC 프레임워크를 사용합니다. Ruby gRPC 클라이언트는
Gitaly 오류를 확인할 때 유용한 정보를 포함할 수 있는 자체 로그 파일을 가지고 있습니다.
gRPC 클라이언트의 로그 수준은 GRPC_LOG_LEVEL 환경 변수를 사용하여 제어할 수 있습니다.
기본 수준은 WARN입니다.

gRPC 추적을 실행하려면:

sudo GRPC_TRACE=all GRPC_VERBOSITY=DEBUG gitlab-rake gitlab:gitaly:check

이 명령이 모든 주소에 연결 실패 오류로 실패하면 SSL 또는 TLS 문제를 확인하세요:

/opt/gitlab/embedded/bin/openssl s_client -connect <gitaly-ipaddress>:<port> -verify_return_error

Verify return code 필드가
알려진 Linux 패키지 설치 구성 문제를 나타내는지 확인하세요.

openssl이 성공하지만 gitlab-rake gitlab:gitaly:check가 실패하는 경우,
Gitaly에 대한 인증서 요구 사항을 확인하세요.

서버 측 gRPC 로그

gRPC 추적은 GODEBUG=http2debug 환경 변수를 사용하여 Gitaly 자체에서 활성화할 수도 있습니다. Linux 패키지 설치에서 이를 설정하려면:

  1. gitlab.rb 파일에 다음 내용을 추가합니다:

    gitaly['env'] = {
  "GODEBUG=http2debug" => "2"
}

  2. GitLab 재구성합니다.

Git 프로세스를 RPC와 연관시키기

때때로 특정 Git 프로세스를 생성한 Gitaly RPC를 찾아야 할 필요가 있습니다.

이 작업을 수행하는 한 가지 방법은 DEBUG 로깅을 사용하는 것입니다. 하지만 이는 사전에 활성화해야 하며, 생성된 로그는 다소 상세합니다.

이 상관관계를 확인하기 위한 가벼운 방법은 Git 프로세스의 환경을 검사하고 CORRELATION_ID 변수를 살펴보는 것입니다:

PID=<Git process ID>
sudo cat /proc/$PID/environ | tr '\0' '\n' | grep ^CORRELATION_ID=

이 방법은 git cat-file 프로세스에 대해 신뢰할 수 없는데, Gitaly가 내부적으로 이를 풀링하고 RPC 간에 재사용하기 때문입니다.

리포지토리 변경이 401 Unauthorized 오류로 실패

Gitaly를 단독 서버에서 실행하고 다음과 같은 조건이 발생하는 경우:

  • 사용자가 SSH 및 HTTPS를 사용하여 리포지토리를 성공적으로 클론하고 가져올 수 있습니다.
  • 사용자가 리포지토리에 푸시할 수 없거나 웹 UI에서 변경을 시도할 때 401 Unauthorized 메시지를 받습니다.

Gitaly는 잘못된 비밀 파일로 인해 Gitaly 클라이언트와 인증에 실패할 수 있습니다.

다음이 모두 사실인지 확인하세요:

  • 어떤 사용자가 이 Gitaly 서버의 리포지토리에 git push를 수행할 때 401 Unauthorized 오류가 발생합니다:

    remote: GitLab: 401 Unauthorized
To <REMOTE_URL>
! [remote rejected] branch-name -> branch-name (pre-receive hook declined)
error: failed to push some refs to '<REMOTE_URL>'
  • 어떤 사용자가 GitLab UI를 사용하여 리포지토리에서 파일을 추가하거나 수정할 때 즉시 빨간색 401 Unauthorized 배너가 표시됩니다.
  • 새 프로젝트를 생성하고 README로 초기화할 경우 프로젝트는 성공적으로 생성되지만 README는 생성되지 않습니다.

  • Gitaly 클라이언트에서 로그를 tailing 할 때 오류를 재현하면 /api/v4/internal/allowed 엔드포인트에 도달할 때 401 오류가 발생합니다:

    # api_json.log
{
  "time": "2019-07-18T00:30:14.967Z",
  "severity": "INFO",
  "duration": 0.57,
  "db": 0,
  "view": 0.57,
  "status": 401,
  "method": "POST",
  "path": "\/api\/v4\/internal\/allowed",
  "params": [
    {
      "key": "action",
      "value": "git-receive-pack"
    },
    {
      "key": "changes",
      "value": "REDACTED"
    },
    {
      "key": "gl_repository",
      "value": "REDACTED"
    },
    {
      "key": "project",
      "value": "\/path\/to\/project.git"
    },
    {
      "key": "protocol",
      "value": "web"
    },
    {
      "key": "env",
      "value": "{\"GIT_ALTERNATE_OBJECT_DIRECTORIES\":[],\"GIT_ALTERNATE_OBJECT_DIRECTORIES_RELATIVE\":[],\"GIT_OBJECT_DIRECTORY\":null,\"GIT_OBJECT_DIRECTORY_RELATIVE\":null}"
    },
    {
      "key": "user_id",
      "value": "2"
    },
    {
      "key": "secret_token",
      "value": "[FILTERED]"
    }
  ],
  "host": "gitlab.example.com",
  "ip": "REDACTED",
  "ua": "Ruby",
  "route": "\/api\/:version\/internal\/allowed",
  "queue_duration": 4.24,
  "gitaly_calls": 0,
  "gitaly_duration": 0,
  "correlation_id": "XPUZqTukaP3"
}

# nginx_access.log
[IP] - - [18/Jul/2019:00:30:14 +0000] "POST /api/v4/internal/allowed HTTP/1.1" 401 30 "" "Ruby"

이 문제를 해결하려면 Gitaly 서버의 gitlab-secrets.json 파일이 Gitaly 클라이언트의 파일과 일치하는지 확인합니다. 일치하지 않으면 Gitaly 서버의 비밀 파일을 Gitaly 클라이언트에 맞게 업데이트한 후 재구성합니다.

모든 Gitaly 서버 및 클라이언트에서 gitlab-secrets.json 파일이 동일하다는 것을 확인했다면, 애플리케이션이 다른 파일에서 이 비밀을 가져오고 있을 수 있습니다. Gitaly 서버의 config.toml 파일에서 사용 중인 비밀 파일을 확인할 수 있습니다. 해당 설정이 누락되면 GitLab은 /opt/gitlab/embedded/service/gitlab-rails/.gitlab_shell_secret에 있는 .gitlab_shell_secret를 기본 사용합니다.

리포지토리 푸시가 401 Unauthorized 및 JWT::VerificationError로 실패하는 경우

git push를 시도할 때 다음과 같은 메시지를 볼 수 있습니다:

  • 401 Unauthorized 오류.

  • 서버 로그에서 다음과 같은 내용:

    {
  ...
  "exception.class":"JWT::VerificationError",
  "exception.message":"Signature verification raised",
  ...
}

이 오류 조합은 GitLab 서버가 GitLab 15.5 이상으로 업그레이드되었으나 Gitaly가 아직 업그레이드되지 않은 경우 발생합니다.

GitLab 15.5부터 GitLab은 공유 비밀 대신 JWT 토큰을 사용하여 GitLab Shell과 인증합니다.

외부 Gitaly 업그레이드에 대한 권장 사항을 따르고 GitLab 서버보다 먼저 Gitaly를 업그레이드해야 합니다.

리포지토리 푸시가 deny updating a hidden ref 오류로 실패하는 경우

Gitaly에는 사용자가 업데이트할 수 없는 읽기 전용 내장 GitLab 참조가 있습니다. 내부 참조를 git push --mirror로 업데이트하려고 하면 Git은 deny updating a hidden ref 거부 오류를 반환합니다.

읽기 전용 참조는 다음과 같습니다:

  • refs/environments/
  • refs/keep-around/
  • refs/merge-requests/
  • refs/pipelines/

브랜치와 태그만 미러 푸시하고 보호된 참조를 미러 푸시하려고 시도하지 않으려면 다음을 실행하세요:

git push origin +refs/heads/*:refs/heads/* +refs/tags/*:refs/tags/*

관리자가 푸시하려는 다른 네임스페이스도 추가 패턴을 통해 포함할 수 있습니다.

명령줄 도구가 Gitaly에 연결할 수 없는 경우

gRPC가 Gitaly 서버에 도달할 수 없는 경우:

  • 명령줄 도구로 Gitaly 서버에 연결할 수 없습니다.
  • 특정 작업에서 14: Connect Failed 오류 메시지가 발생합니다.

TCP를 사용하여 Gitaly에 도달할 수 있는지 확인하세요:

sudo gitlab-rake gitlab:tcp_check[GITALY_SERVER_IP,GITALY_LISTEN_PORT]

TCP 연결이:

  • 실패하면 네트워크 설정 및 방화벽 규칙을 확인합니다.
  • 성공하면 네트워킹 및 방화벽 규칙이 올바릅니다.

Bash와 같은 명령줄 환경에서 프록시 서버를 사용하는 경우 이는 gRPC 트래픽에 방해가 될 수 있습니다.

Bash 또는 호환 가능한 명령줄 환경을 사용하고 있는 경우, 다음 명령을 실행하여 프록시 서버가 구성되어 있는지 확인하세요:

echo $http_proxy
echo $https_proxy

이 변수 중 하나라도 값이 있으면 Gitaly CLI 연결이 Gitaly에 연결할 수 없는 프록시를 통해 라우팅되고 있을 수 있습니다.

프록시 설정을 제거하려면 (어떤 변수가 값이 있었는지에 따라) 다음 명령을 실행하세요:

unset http_proxy
unset https_proxy

리포지토리에 접근할 때 Gitaly 또는 Praefect 로그에 나타나는 권한 거부 오류

Gitaly 및 Praefect 로그에서 다음과 같은 내용을 볼 수 있습니다:

{
  ...
  "error":"rpc error: code = PermissionDenied desc = permission denied",
  "grpc.code":"PermissionDenied",
  "grpc.meta.client_name":"gitlab-web",
  "grpc.request.fullMethod":"/gitaly.ServerService/ServerInfo",
  "level":"warning",
  "msg":"finished unary call with code PermissionDenied",
  ...
}

이 로그의 정보는 gRPC 호출 오류 응답 코드입니다.

이 오류가 발생하면, Gitaly 인증 토큰이 올바르게 설정되어 있어도, Gitaly 서버에서 시계 드리프트가 발생하고 있는 것일 수 있습니다. Gitaly로 전송되는 인증 토큰에는 타임스탬프가 포함되어 있습니다. 유효하다고 간주되려면 Gitaly는 해당 타임스탬프가 Gitaly 서버 시간의 60초 이내여야 합니다.

Gitaly 클라이언트와 서버가 동기화되었는지 확인하고, 네트워크 시간 프로토콜(NTP) 시간 서버를 사용하여 동기화를 유지합니다.

Gitaly가 재구성 후 새 주소에서 수신 대기하지 않음

gitaly['configuration'][:listen_addr] 또는 gitaly['configuration'][:prometheus_listen_addr] 값을 업데이트할 때, Gitaly가 sudo gitlab-ctl reconfigure 후에도 이전 주소에서 계속 수신 대기할 수 있습니다.

이 경우, 문제를 해결하기 위해 sudo gitlab-ctl restart를 실행하세요. 이는 더 이상 필요하지 않아야 하며, 이 문제는 해결되었습니다.

독립형 Gitaly 노드에서 레포지토리에 접근 시 Gitaly 로그의 오류

독립형 Gitaly 노드에서 레포지토리에 접근할 때 Gitaly 로그에서 권한 거부 오류를 볼 수 있습니다. 이 오류는 파일 권한이 올바르더라도 발생합니다.

Gitaly 노드가 시계 드리프트를 경험하고 있을 가능성이 높습니다.

가능하다면 GitLab과 Gitaly 노드가 동기화되어 있는지 확인하고 NTP 시간 서버를 사용하여 동기화 상태를 유지하세요.

헬스 체크 경고

/var/log/gitlab/praefect/current에서 다음 경고는 무시할 수 있습니다.

"error":"full method name not found: /grpc.health.v1.Health/Check",
"msg":"error when looking up method info"

파일을 찾을 수 없는 오류

/var/log/gitlab/gitaly/current에서 다음 오류는 무시할 수 있습니다.

이 오류는 GitLab Rails 응용 프로그램이 레포지토리에 존재하지 않는 특정 파일을 확인할 때 발생합니다.

"error":"not found: .gitlab/route-map.yml"
"error":"not found: Dockerfile"
"error":"not found: .gitlab-ci.yml"

Dynatrace가 활성화되면 Git 푸시가 느림

Dynatrace는 sudo -u git -- /opt/gitlab/embedded/bin/gitaly-hooks 참조 트랜잭션 훅이 시작되고 종료되는 데 몇 초가 걸리도록 만들 수 있습니다. 사용자가 푸시할 때 gitaly-hooks가 두 번 실행되므로 상당한 지연이 발생합니다.

Dynatrace가 활성화된 상태에서 Git 푸시가 너무 느린 경우 Dynatrace를 비활성화하세요.

gitaly check가 401 상태 코드로 실패

gitaly check는 Gitaly가 내부 GitLab API에 접근할 수 없는 경우 401 상태 코드로 실패할 수 있습니다.

이를 해결하는 한 가지 방법은 gitlab.rb의 GitLab 내부 API URL에 대한 항목이 올바른지 확인하는 것입니다. 이는 gitlab_rails['internal_api_url']로 설정되어야 합니다.

Gitaly TLS를 사용할 때 새 병합 요청에 대한 변경 사항(차이)이 로드되지 않음

Gitaly with TLS를 활성화한 후, 새 병합 요청에 대한 변경 사항(차이)이 생성되지 않으며 GitLab에서 다음 메시지를 볼 수 있습니다.

병합 요청을 구축하는 중입니다... 빌드가 완료되면 이 페이지가 업데이트됩니다.

Gitaly가 일부 작업을 완료하기 위해 스스로 연결할 수 있어야 합니다. Gitaly 인증서가 Gitaly 서버에 의해 신뢰되지 않는 경우 병합 요청 차이를 생성할 수 없습니다.

Gitaly가 스스로 연결할 수 없는 경우, 다음과 같은 메시지를 Gitaly 로그에서 볼 수 있습니다.

{
   "level":"warning",
   "msg":"[core] [Channel #16 SubChannel #17] grpc: addrConn.createTransport failed to connect to {Addr: \"ext-gitaly.example.com:9999\", ServerName: \"ext-gitaly.example.com:9999\", }. Err: connection error: desc = \"transport: authentication handshake failed: tls: failed to verify certificate: x509: certificate signed by unknown authority\"",
   "pid":820,
   "system":"system",
   "time":"2023-11-06T05:40:04.169Z"
}
{
   "level":"info",
   "msg":"[core] [Server #3] grpc: Server.Serve failed to create ServerTransport: connection error: desc = \"ServerHandshake(\\\"x.x.x.x:x\\\") failed: wrapped server handshake: remote error: tls: bad certificate\"",
   "pid":820,
   "system":"system",
   "time":"2023-11-06T05:40:04.169Z"
}

문제를 해결하려면 Gitaly 서버의 /etc/gitlab/trusted-certs 폴더에 Gitaly 인증서를 추가했는지 확인하고:

  1. GitLab 재구성하기하여 인증서가 심볼릭 링크 되도록 하세요.

  2. Gitaly 프로세스가 인증서를 로드할 수 있도록 수동으로 Gitaly를 재시작하세요: sudo gitlab-ctl restart gitaly.

Gitaly의 noexec 파일 시스템에서 프로세스 포크 실패

마운트 지점에 noexec 옵션을 적용하면 (예: /var) Gitaly에서 프로세스 포크와 관련된 permission denied 오류가 발생합니다. 예를 들어:

fork/exec /var/opt/gitlab/gitaly/run/gitaly-2057/gitaly-git2go: permission denied

이 문제를 해결하려면 파일 시스템 마운트에서 noexec 옵션을 제거하십시오. 대안으로 Gitaly 런타임 디렉토리를 변경할 수 있습니다:

  1. /etc/gitlab/gitlab.rb에 gitaly['runtime_dir'] = '<PATH_WITH_EXEC_PERM>'를 추가하고 noexec가 설정되지 않은 위치를 지정합니다.

  2. sudo gitlab-ctl reconfigure를 실행합니다.

커밋 서명 오류 발생: invalid argument 또는 invalid data

커밋 서명이 다음 오류 중 하나로 실패하는 경우:

  • invalid argument: signing key is encrypted
  • invalid data: tag byte does not have MSB set

이 오류는 Gitaly 커밋 서명이 헤드리스 상태이고 특정 사용자와 연결되지 않았기 때문에 발생합니다. GPG 서명 키는 비밀번호 없이 생성되어야 하며, 내보내기 전에 비밀번호를 제거해야 합니다.

Gitaly 로그에서 info 메시지의 오류 표시

GitLab 16.3에서 도입된 버그로 인해 추가 항목이 Gitaly 로그에 기록되었습니다. 이러한 로그 항목은 "level":"info"를 포함하고 있지만 msg 문자열은 오류를 포함한 것으로 보였습니다.

예를 들어:

{"level":"info","msg":"[core] [Server #3] grpc: Server.Serve failed to create ServerTransport: connection error: desc = \"ServerHandshake(\\\"x.x.x.x:x\\\") failed: wrapped server handshake: EOF\"","pid":6145,"system":"system","time":"2023-12-14T21:20:39.999Z"}

이 로그 항목의 이유는 기본 gRPC 라이브러리가 때때로 자세한 전송 로그를 출력하기 때문입니다. 이러한 로그 항목은 오류처럼 보이지만, 일반적으로 무시해도 안전합니다.

이 버그는 GitLab 16.4.5, 16.5.5 및 16.6.0에서 수정되었습니다, 이로 인해 이러한 유형의 메시지가 Gitaly 로그에 기록되는 것을 방지합니다.

Gitaly 프로파일링

Gitaly는 Prometheus 리스닝 포트에서 여러 Go 내장 성능 프로파일링 도구를 노출합니다. 예를 들어, Prometheus가 GitLab 서버의 포트 9236에서 리스닝하고 있는 경우:

  • 실행 중인 goroutines 목록과 그 백트레이스를 가져옵니다:

    curl --output goroutines.txt "http://<gitaly_server>:9236/debug/pprof/goroutine?debug=2"

  • 30초 동안 CPU 프로파일을 실행합니다:

    curl --output cpu.bin "http://<gitaly_server>:9236/debug/pprof/profile"

  • 힙 메모리 사용량을 프로파일링합니다:

    curl --output heap.bin "http://<gitaly_server>:9236/debug/pprof/heap"

  • 5초 실행 추적을 기록합니다. 이는 실행 중 Gitaly 성능에 영향을 미칩니다:

    curl --output trace.bin "http://<gitaly_server>:9236/debug/pprof/trace?seconds=5"

go가 설치된 호스트에서 CPU 프로파일과 힙 프로파일을 브라우저에서 볼 수 있습니다:

go tool pprof -http=:8001 cpu.bin
go tool pprof -http=:8001 heap.bin

실행 추적은 다음을 실행하여 볼 수 있습니다:

go tool trace heap.bin

프로파일 Git 작업


자체 관리 GitLab에서는 기본적으로 이 기능을 사용할 수 없습니다. 사용 가능하게 하려면, 관리자가 기능 플래그를 활성화해야 합니다
log_git_traces라는 이름으로. GitLab.com에서는 이 기능이 사용 가능하지만 GitLab.com 관리자만 구성할 수 있습니다. GitLab Dedicated에서는 이 기능을 사용할 수 없습니다.

Gitaly에서 수행하는 Git 작업에 대한 추가 정보를 Gitaly 로그에 보내 프로파일링할 수 있습니다. 이 정보로 사용자는 성능 최적화, 디버깅 및 일반 텔레메트리 수집을 위한 인사이트를 더 얻을 수 있습니다. 자세한 내용은 Git Trace2 API 참조를 참조하세요.

시스템 과부하를 방지하기 위해, 추가 정보 로그는 속도 제한이 있습니다. 속도 제한이 초과되면, 추적이 건너뛰어집니다. 그러나 속도가 건강한 상태로 돌아온 후, 추적이 다시 자동으로 처리됩니다. 속도 제한은 시스템이 안정적으로 유지되도록 하고 지나치게 많은 추적 처리로 인한 부정적인 영향을 피하도록 보장합니다.

GitLab 복원 후 리포지토리가 비어 있는 것으로 표시됨

보안을 강화하기 위해 fapolicyd를 사용하는 경우, GitLab은 GitLab 백업 파일에서 복원이 성공했음을 보고할 수 있지만:

  • 리포지토리가 비어 있는 것으로 표시됩니다.

  • 새 파일 생성 시 비슷한 오류가 발생합니다:

    13:commit: commit: starting process [/var/opt/gitlab/gitaly/run/gitaly-5428/gitaly-git2go -log-format json -log-level -correlation-id
01GP1383JV6JD6MQJBH2E1RT03 -enabled-feature-flags -disabled-feature-flags commit]: fork/exec /var/opt/gitlab/gitaly/run/gitaly-5428/gitaly-git2go: operation not permitted.

  • Gitaly 로그에는 비슷한 오류가 포함될 수 있습니다:

     "error": "exit status 128, stderr: \"fatal: cannot exec '/var/opt/gitlab/gitaly/run/gitaly-5428/hooks-1277154941.d/reference-transaction':

  Operation not permitted\\nfatal: cannot exec '/var/opt/gitlab/gitaly/run/gitaly-5428/hooks-1277154941.d/reference-transaction': Operation
  not permitted\\nfatal: ref updates aborted by hook\\n\"",
 "grpc.code": "Internal",
 "grpc.meta.deadline_type": "none",
 "grpc.meta.method_type": "client_stream",
 "grpc.method": "FetchBundle",
 "grpc.request.fullMethod": "/gitaly.RepositoryService/FetchBundle",
...

디버그 모드를 사용하여 fapolicyd가 현재 규칙에 따라 실행을 거부하고 있는지 확인할 수 있습니다.

fapolicyd가 실행을 거부하고 있음을 발견한 경우 다음을 고려하세요:

  1. fapolicyd 구성에서 /var/opt/gitlab/gitaly의 모든 실행 파일을 허용하세요:

    allow perm=any all : ftype=application/x-executable dir=/var/opt/gitlab/gitaly/

  2. 서비스를 재시작하세요:

    sudo systemctl restart fapolicyd

sudo gitlab-ctl restart gitaly

Pre-receive hook declined 오류 RHEL 인스턴스에 fapolicyd가 활성화된 상태에서 푸시할 때

fapolicyd가 활성화된 RHEL 기반 인스턴스에 푸시할 때 Pre-receive hook declined 오류가 발생할 수 있습니다. 이 오류는 fapolicyd가 Gitaly 바이너리의 실행을 차단할 수 있기 때문에 발생할 수 있습니다. 이 문제를 해결하려면 다음 중 하나를 수행하세요:

  • fapolicyd 비활성화.
  • fapolicyd가 활성화된 상태에서 Gitaly 바이너리 실행을 허용하는 fapolicyd 규칙 생성.

Gitaly 바이너리 실행을 허용하는 규칙을 만들려면:

  1. /etc/fapolicyd/rules.d/89-gitlab.rules에 파일 생성.

  2. 파일에 다음 내용을 입력합니다:

    allow perm=any all : ftype=application/x-executable dir=/var/opt/gitlab/gitaly/

  3. 서비스를 재시작합니다:

    systemctl restart fapolicyd

새 규칙은 데몬이 재시작된 후에 효과가 발생합니다.

중복 경로가 있는 저장소 제거 후 저장소 업데이트

History
  • Rake 작업 gitlab:gitaly:update_removed_storage_projects 도입됨 GitLab 17.1.

GitLab 17.0에서 중복 경로를 가진 저장소 구성에 대한 지원이 제거됨. 이는 gitaly 구성에서 중복 저장소 구성을 제거해야 함을 의미할 수 있습니다.

경고: 구형 저장소와 신형 저장소가 동일한 Gitaly 서버의 동일한 디스크 경로를 공유하는 경우에만 이 Rake 작업을 사용하세요. 다른 상황에서 이 Rake 작업을 사용하면 저장소가 사용할 수 없게 됩니다. 다른 모든 상황에서는 프로젝트 저장소 이동 API를 사용하여 저장소 간에 프로젝트를 이동하세요.

Gitaly 구성에서 다른 저장소와 동일한 경로를 사용하는 저장소를 제거할 때, 구형 저장소와 관련된 프로젝트는 신형 저장소로 재배정되어야 합니다.

예를 들어, 다음과 유사한 구성이 있을 수 있습니다:

gitaly['configuration'] = {
  storage: [
    {
       name: 'default',
       path: '/var/opt/gitlab/git-data/repositories',
    },
    {
       name: 'duplicate-path',
       path: '/var/opt/gitlab/git-data/repositories',
    },
  ],
}

구성에서 duplicate-path를 제거하는 경우, 할당된 프로젝트를 default와 연결하기 위해 다음 Rake 작업을 실행합니다:

Linux 패키지 설치
sudo gitlab-rake "gitlab:gitaly:update_removed_storage_projects[duplicate-path, default]"
자체 컴파일 설치
sudo -u git -H bundle exec rake "gitlab:gitaly:update_removed_storage_projects[duplicate-path, default]" RAILS_ENV=production