Gitaly 문제 해결

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

Gitaly 문제를 해결할 때 아래 정보를 참조하십시오. Gitaly Cluster (Praefect)를 해결하는 정보는 Gitaly Cluster 문제 해결을 참조하십시오.

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

또한 Gitaly timeout 설정을 확인하고, gitaly/current 파일을 구문 분석하는 데 대한 권장 사항을 참조하십시오.

스탠드얼론 Gitaly 서버를 사용할 때 버전 확인

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

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

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

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

Gitlab::GitalyClient::ServerService.new("default").storage_disk_statistics
# For 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 및 fetching folder content 오류

fetching folder content 및 경우에 따라 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 클라이언트의 로그를 트래킹하고 오류를 재현하는 경우, 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 클라이언트와 일치하도록 업데이트한 후 재구성하십시오.

만약 gitlab-secrets.json 파일이 Gitaly 서버 및 클라이언트 간에 동일하다는 것을 확인했다면, 애플리케이션이 다른 파일에서 이 시크릿을 가져오고 있는지 확인하십시오. 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을 인증합니다. GitLab 서버 전에 외부 Gitaly를 업그레이드하기 위해 추천되는 지침을 따라야 합니다.

리포지터리 푸시가 deny updating a hidden ref 오류와 실패함

GitLab 13.12에서 소개된 변경으로 인해 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 클라이언트와 서버가 동기화되어 있는지 확인하고, NTP 시간 서버를 사용하여 동기화를 유지하세요.

Gitaly가 구성을 다시 하는 후에 새 주소에서 청취하지 않음

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

이 경우 sudo gitlab-ctl restart를 실행하여 문제를 해결하세요. 이 이슈가 해결되었으므로 더 이상 필요하지 않을 것입니다.

독립형 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는 사용자가 푸시할 때 /opt/gitlab/embedded/bin/gitaly-hooks 참조 트랜잭션 후크를 활성화하고 해제하는 데 몇 초가 걸릴 수 있습니다. 사용자가 푸시할 때 gitaly-hooks가 두 번 실행되어 signifiant한 지연을 으이킵니다.

Dynatrace를 사용 중일 때 Git 푸시가 너무 느린 경우 Dynatrace를 비활성화하세요.

gitaly check가 401 상태 코드로 실패

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

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

새로운 Merge Request을 생성할 때 Gitaly TLS를 사용하는 경우 변경 사항(diffs)이 로드되지 않는 문제

Gitaly with TLS를 활성화 한 후, 새로운 Merge Request에 대한 변경 사항(diffs)이 생성되지 않으며 GitLab에서 다음과 같은 메시지가 표시됩니다: 

Merge Request을 생성 중입니다... 빌드가 완료되면 이 페이지가 업데이트됩니다.

Gitaly는 특정 작업을 완료하기 위해 자체에 연결할 수 있어야 합니다. Gitaly 인증서가 Gitaly 서버에 의해 신뢰되지 않으면 Merge Request diffs를 생성할 수 없습니다.

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

noexec 파일 시스템에 저장된 프로세스의 Gitaly가 fork에 실패하는 문제

예를 들어 /var와 같은 마운트 지점에 noexec 옵션을 적용하는 변경이 GitLab 14.10에서 도입된 결과, Gitaly는 프로세스를 fork하는 중에 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: signing key is encrypted 또는 invalid data: tag byte does not have MSB set.와 같은 commit 서명 실패

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 16.9에서 도입됨, log_git_traces라는 플래그로 활성화됩니다. 기본적으로 비활성화됨.

플래그: Self-managed 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가 실행을 거부하는 것으로 확인되면 다음을 고려해 보세요:

  1. fapolicyd 구성에서 /var/opt/gitlab/gitaly의 모든 실행 파일을 허용합니다: 

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

  2. 서비스를 다시 시작합니다.

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

새 규칙은 데몬을 다시 시작한 후 적용됩니다.