Gitaly 문제 해결

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

Gitaly 문제를 해결할 때 아래 정보를 참조하세요. Gitaly Cluster (Praefect)의 문제 해결 방법은 Gitaly Cluster 문제 해결을 참조하세요.

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

Gitaly timeout 설정 및 gitaly/current 파일 구문 분석에 대한 내용도 참조하세요.

스탠드얼론 Gitaly 서버를 사용하는 경우 버전 확인

스탠드얼론 Gitaly 서버를 사용할 때, GitLab과 완전히 호환되는지 확인하기 위해 서버가 동일한 버전인지 확인해야 합니다:

  1. 왼쪽 사이드바에서 맨 아래에서 관리 영역을 선택합니다.
  2. 개요 > Gitaly 서버를 선택합니다.
  3. 모든 Gitaly 서버가 최신 상태임을 확인합니다.

리포지터리 리소스 세부 정보 찾기

Gitaly 리포지터리의 사용 가능한 공간 및 사용된 공간을 확인하려면 Rails 콘솔에서 다음 명령을 실행할 수 있습니다: 

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

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

remote: GitLab: 401 Unauthorized

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

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

폴더 콘텐츠 가져오기 및 경우에 따라 500 오류는 GitLab과 Gitaly 간의 연결 문제를 나타냅니다. 자세한 내용은 클라이언트 측 gRPC 로그를 참조하세요.

클라이언트 측 gRPC 로그

Gitaly는 gRPC RPC 프레임워크를 사용합니다. Ruby gRPC 클라이언트에는 도움이 될 수 있는 자체 로그 파일이 있습니다. 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

openssl 명령이 성공하지만 gitlab-rake gitlab:gitaly:check이 실패한다면, Gitaly의 인증서 요구 사항을 확인하세요.

서버 측 gRPC 로그

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

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

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

  2. GitLab을 재구성합니다.

Git 프로세스를 RPC와 연관

특정 Git 프로세스를 만든 Gitaly RPC를 찾아야 할 때가 있습니다.

이를 위한 하나의 방법은 DEBUG 로깅을 사용하는 것입니다. 그러나 이는 미리 활성화해야 하며 만들어진 로그는 매우 장황합니다.

이 연관 정도를 확인하는 더 가벼운 방법은 Git 프로세스의 환경을 검사하여 (PID를 사용) CORRELATION_ID 변수를 확인하는 것입니다: 

PID=<Git 프로세스 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 클라이언트에서 로그를 따라갈 때 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 클라이언트와 일치하도록 업데이트한 후 재구성합니다.

gitlab-secrets.json 파일이 모든 Gitaly 서버 및 클라이언트에서 동일하다는 것을 확인했지만 응용 프로그램이 다른 파일에서 이 시크릿을 가져 오고 있다면 확인하세요. Gitaly 서버의 config.toml 파일에서 사용 중인 시크릿 파일을 indicated합니다. 해당 설정이 누락되면 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 셀과 인증합니다. GitLab 서버 보다 먼저 외부 Gitaly 업그레이드에 대한 권장 사항을 따르고 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 오류 메시지가 표시되는 경우.

다음을 사용하여 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 클라이언트 및 서버가 동기화되어 있는지 확인하고, NTP 시간 서버를 사용하여 동기화 유지하세요.

Gitaly 구성을 재구성한 후 새 주소에서 수신 대기하지 않는 경우

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

이 경우 sudo gitlab-ctl restart를 실행하여 문제를 해결하세요. 이 문제는 해결되어 더 이상 이러한 조치가 필요하지 않아야 합니다.

독립적인 Gitaly 노드에서 리포지터리에 액세스할 때 Gitaly 로그에 허가 거부 오류가 표시되는 경우

파일 권한이 올바른데 이 오류가 발생하는 경우 GitLab과 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는 사용자가 푸시할 때 /opt/gitlab/embedded/bin/gitaly-hooks 참조 트랜잭션 후크를 시작하고 종료하는 데 몇 초가 소요될 수 있습니다. 사용자가 푸시할 때 gitaly-hooks가 두 번 실행되어 큰 지연이 발생합니다.

Dynatrace가 활성화되어 있을 때 Git 푸시가 너무 느린 경우 Dynatrace를 비활성화하세요.

gitaly check가 401 상태 코드로 실패하는 경우

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

이를 해결하는 한 가지 방법은 gitlab.rb에 구성된 GitLab 내부 API URL이 올바른지 확인하는 것입니다 gitlab_rails['internal_api_url'].

Gitaly TLS를 사용할 때 새 Merge Request의 변경 사항(차이)이 로드되지 않는 경우

Gitaly TLS를 활성화한 후 새로운 Merge Request의 변경 사항(차이)이 생성되지 않고 다음과 같은 메시지가 표시됩니다: 

Building your merge request... This page will update when the build is complete

Gitaly는 몇 가지 작업을 완료하기 위해 자체에 연결할 수 있어야 합니다. Gitaly 인증서가 Gitaly 서버에 의해 신뢰되지 않는 경우 Merge Request의 변경 사항이 생성되지 않습니다.

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 인증서를 Gitaly 서버의 /etc/gitlab/trusted-certs 폴더에 추가하고:

  1. GitLab을 다시 구성하여 인증서가 심볼릭 링크로 설정되도록 합니다.
  2. 인증서가 Gitaly 프로세스에 의해 로드되도록 Gitaly를 매뉴얼으로 다시 시작합니다. sudo gitlab-ctl restart gitaly

Gitaly가 noexec 파일 시스템에 저장된 프로세스를 fork하지 못하는 문제

마운트 지점(for example, /var)에 noexec 옵션을 적용하면 Gitaly가 프로세스를 fork하는데 관련된 허가 거부 오류가 발생합니다. 예를 들어: 

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: 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 및 그들의 backtrace 디렉터리 가져오기: 

    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 16.9에서 도입된 기능으로, log_git_traces라는 플래그와 함께 사용됩니다. 기본으로 비활성화됨.
Self-Managed GitLab에서는 이 기능이 기본적으로 사용할 수 없습니다. 사용 가능하게 만들려면 관리자가 이름이 log_git_traces인 피처 플래그를 활성화해야 합니다. GitLab.com에서는 이 기능을 사용할 수 있지만, 설정은 GitLab.com 관리자만 할 수 있습니다. GitLab Dedicated에서는 이 기능을 사용할 수 없습니다.

Gitaly가 수행하는 Git 작업을 프로파일링할 수 있습니다. 이를 통해 사용자는 성능 최적화, 디버깅 및 일반적인 테레메트리 수집을 위해 Git 작업에 대한 추가 정보를 보다 자세히 확인할 수 있습니다. 자세한 정보는 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가 거부하는지 여부를 확인하는 데 도움을 받을 수 있습니다.

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

fapolicyd를 사용하여 RHEL 인스턴스로 푸시할 때 Pre-receive hook declined 오류가 발생하는 경우

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

  • fapolicyd 비활성화
  • fapolicyd에서 Gitaly 실행 파일의 실행을 허용하는 규칙 생성

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

새 규칙은 데몬이 다시 시작되면 적용됩니다.