Gitaly 문제 해결

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

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

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

또한 Gitaly 타임아웃 설정 및 gitaly/current 파일 구문 분석에 대한 조언을 참조하십시오.

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

독립형 Gitaly 서버를 사용할 때 전체 호환성을 보장하기 위해 GitLab 버전과 동일한 버전인지 확인해야 합니다.

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

저장소 리소스 세부 정보 찾기

Rails 콘솔에서 다음 명령을 실행하여 Gitaly 저장소의 사용 가능한 공간 및 사용된 공간을 확인할 수 있습니다: 

Gitlab::GitalyClient::ServerService.new("default").storage_disk_statistics
# Gitaly Cluster의 경우
Gitlab::GitalyClient::ServerService.new("<저장소 이름>").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를 사용하여 저장소를 성공적으로 복제하고 가져올 수 있습니다.
  • 사용자가 저장소에 푸시 할 수 없거나 변경을 시도 할 때 401 Unauthorized 메시지를 수신합니다.

Gitaly는 잘못된 secrets 파일로 인해 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 /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 서버의 secrets 파일을 Gitaly 클라이언트와 일치하도록 업데이트 한 다음 재구성하십시오.

모든 Gitaly 서버 및 클라이언트에서 gitlab-secrets.json 파일이 동일한지 확인한 후에도 응용 프로그램이 다른 파일에서이 시크릿을 가져 오도록 할 수 있습니다. Gitaly 서버의 config.toml 파일은 사용중인 secrets 파일을 나타냅니다. 해당 설정이 누락된 경우 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를 업그레이드하기 위해 외부 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가 두 번 실행되어 큰 지연을 일으킵니다.

Git 푸시가 Dynatrace를 활성화했을 때 너무 느리다면 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 파일 시스템에 저장된 프로세스 fork에 실패하는 경우

GitLab 14.10에서 발생한 변경 사항으로 noexec 옵션을 마운트 지점(예: /var)에 적용하면 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'] = '<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 및 해당 백트레이스 목록 가져오기: 

    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 작업에 대한 추가 정보를 보낼 수 있습니다. 이를 통해 사용자는 성능 최적화, 디버깅 및 일반적인 텔레메트리 수집을 위해 더 많은 통찰력을 얻게 됩니다. 자세한 내용은 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. 서비스를 다시 시작합니다.

RHEL 인스턴스에서 fapolicyd를 활성화한 상태로 푸시할 때 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

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