VPS 시스템 시간 오차 원인과 동기화 해결 방법

VPS의 시스템 시간이 어긋나는 이유

VPS의 시스템 시간이 어긋나는 이유는 시간을 보정하는 작업이 수행되지 않기 때문입니다. 커널은 하드웨어 카운터를 기준으로 시간을 계산하는데, 이 카운터는 미세하게 빠르거나 느리게 작동합니다. 시간 동기화 클라이언트가 실행되지 않으면 이 작은 오차가 매시간 누적됩니다. 가상 머신 내부에는 또 다른 원인이 있습니다. 게스트 운영체제는 다른 게스트와 물리 CPU를 공유하므로, CPU를 할당받지 못한 시간 동안에는 시간을 계산할 수 없습니다.

최신 KVM 게스트에서는 카운터 자체가 문제인 경우는 드뭅니다. 패러가상화(paravirtual) kvm-clock 소스는 호스트가 유지하는 값을 읽어오므로, 정상적인 게스트는 호스트의 시간과 거의 일치하게 동작합니다. 시간이 눈에 띄게 틀린다면 보통은 더 단순한 이유 때문입니다. 시간 동기화 데몬이 실행되지 않았거나, 두 개의 데몬이 서로 충돌하고 있거나, 아웃바운드 UDP 포트 123번이 서비스 제공자의 네트워크를 통과하지 못하는 경우입니다. 게스트는 자체 오실레이터가 아닌 호스트나 NTP(network time protocol)로부터 시간 정보를 받아 동기화합니다.

시스템 시계 불일치가 초래하는 문제

• TOTP(시간 기반 일회용 비밀번호) 2단계 인증 코드가 일치하지 않게 되어, 올바른 비밀번호와 키를 사용하더라도 서버에 접속할 수 없게 됩니다.
• 1분 전에 발급된 인증서가 거부되며, curl는 SSL certificate problem: certificate is not yet valid를 출력합니다.
• apt update은 E: Release file for ... is not valid yet (invalid for another 1d 2h 3min 4s) 오류와 함께 저장소 접근을 거부합니다.
• 예약된 작업이 잘못된 시점에 실행되며, 시계가 갑자기 변하면 특정 작업이 두 번 실행되거나 아예 건너뛰어질 수 있습니다.
• 두 서버의 로그를 시간순으로 정렬할 수 없어, 사고 발생 경위를 추측에 의존하여 재구성해야 합니다.

허용 오차는 대부분의 사람이 예상하는 것보다 훨씬 작습니다. 아래 수치는 테스트를 통해 측정한 값이 아니라 문서화된 기본값입니다.

[
  {
    "label": "TLS certificate boundary",
    "tolerance_seconds": 0,
    "documented_in": "RFC 5280"
  },
  {
    "label": "chrony steps instead of slewing",
    "tolerance_seconds": 1,
    "documented_in": "Debian and Ubuntu chrony.conf"
  },
  {
    "label": "TOTP code, one time step",
    "tolerance_seconds": 30,
    "documented_in": "RFC 6238"
  },
  {
    "label": "Kerberos clock skew",
    "tolerance_seconds": 300,
    "documented_in": "MIT krb5 default"
  }
]

TOTP 코드는 30초마다 증가하는 카운터를 기반으로 계산되며, 대부분의 검증기는 앞뒤로 한 단계의 오차까지는 허용합니다. 양방향으로 30초의 오차가 전체 허용 범위의 전부입니다. Kerberos는 이보다 훨씬 관대하여 기본적으로 300초의 오차를 허용합니다. 반면 인증서는 전혀 관대하지 않습니다. 인증서는 고정된 시점을 기준으로 0초의 유예 기간을 두고 검증되므로, 시계가 1초만 빨라도 완벽하게 유효한 인증서가 거부됩니다.

세 가지 시계와 중요한 시계

시스템 시계(system clock)가 가장 중요합니다. 이는 커널의 CLOCK_REALTIME입니다. 1970년 1월 1일 UTC 이후 경과된 초를 메모리에 유지하며, 타임스탬프를 기록하는 모든 곳에서 이 값을 읽습니다. 로그 라인, 인증서 검증, TOTP 코드, 파일 수정 시간 등이 모두 이 시계를 기준으로 합니다. 누군가 서버 시간이 틀렸다고 말한다면, 바로 이 시계를 의미하는 것입니다.

하드웨어 시계(hardware clock)는 RTC(real time clock)라고도 하며, 기기 전원이 꺼져 있어도 계속 작동하는 별도의 카운터입니다. 물리 서버에서는 배터리로 구동되는 칩입니다. 가상 머신 내부에서는 하이퍼바이저가 이를 에뮬레이션하므로, 사실상 호스트의 산물입니다. 리눅스는 부팅 시점에 이 값을 한 번 읽어 시작 시간으로 삼고, 이후에는 자체적으로 시간을 계산합니다. timedatectl는 RTC time 라인에 이 값을 출력합니다. VPS 환경에서는 이 라인을 보고 디버깅하지 마십시오. 이는 시스템 시계의 동기화 상태가 아니라 호스트가 인식하는 시간을 보여주기 때문입니다. 컨테이너에는 일반적으로 /dev/rtc가 존재하지 않으므로, hwclock --show를 실행하면 hwclock: Cannot access the Hardware Clock via any known method. 오류가 발생합니다.

클록소스(clocksource)는 커널이 시계 값을 읽는 사이사이에 시간을 계산하는 기준입니다. 커널이 어떤 것을 선택했는지 확인하려면 다음 명령을 사용하십시오.

cat /sys/devices/system/clocksource/clocksource0/current_clocksource
cat /sys/devices/system/clocksource/clocksource0/available_clocksource

KVM 환경에서는 보통 kvm-clock가 표시됩니다. 이는 호스트가 유지하는 값을 읽어오는 방식이므로, NTP 클라이언트가 없어도 KVM 게스트는 어느 정도 정확한 시간을 유지합니다. tsc는 CPU 자체의 카운터입니다. Xen 게스트는 xen을 보고하며, Hyper-V 게스트는 hyperv 소스를 보고합니다. 커널은 이미 해당 하드웨어에서 가장 신뢰할 수 있는 소스를 선택하므로, 측정된 명확한 이유가 없다면 이 설정을 변경하지 마십시오.

일부 호스트는 PTP(precision time protocol) 장치를 게스트에 제공하여, 네트워크를 거치지 않고 chrony가 호스트 시계를 직접 읽을 수 있게 합니다. 확인해 볼 가치가 있으나, 공유 VPS에서는 사용할 수 없는 경우가 많습니다.

sudo modprobe ptp_kvm
ls /dev/ptp*
cat /sys/class/ptp/ptp0/clock_name

modprobe 명령이 실패하거나 장치가 나타나지 않는다면, 호스트가 해당 기능을 제공하지 않는 것이므로 네트워크 NTP를 사용해야 합니다. clock_name가 KVM 가상 클록을 가리킨다면, 설정 파일에 refclock PHC /dev/ptp0 poll 2 라인을 추가하여 chrony가 이를 사용하도록 할 수 있습니다.

로컬 머신의 시간 상태 확인하기

하나의 명령어로 시작합니다. 이 명령어는 "현재 이 시계를 올바르게 유지하는 주체가 있는가"라는 질문에 한 화면으로 답합니다.

timedatectl

기억에 의존하지 말고 다음 항목들을 직접 읽어 확인하십시오.

• Local time과 Universal time는 각각 로컬 시간대와 UTC로 출력된 동일한 시점입니다. 두 값이 같다면 머신은 이미 UTC로 설정된 상태입니다.
• RTC time은 앞서 설명한 하드웨어 시계입니다. VPS 환경이라면 무시해도 좋습니다.
• Time zone는 시스템이 로컬 시간을 형식화하는 데 사용하는 설정입니다.
• System clock synchronized는 커널 자체의 플래그입니다. 시간 데몬은 소스를 신뢰할 수 있을 때 이 플래그를 설정하므로, no은 부팅 이후 시계를 보정하는 주체가 없었음을 의미합니다.
• NTP service은 systemd-timesyncd의 상태를 보고합니다. chrony를 실행 중인 머신에서 n/a이 출력되는 것은 정상입니다. timesyncd가 설치되어 있지 않기 때문입니다. System clock synchronized: yes와 NTP service: n/a이 함께 나타난다면 chrony가 정상적으로 작동 중이며 커널도 이를 신뢰하고 있다는 뜻입니다.

다음으로, 오차가 얼마나 발생하는지 확인하십시오. 휴대폰 시간과 눈대중으로 비교하지 마십시오. chrony가 실행 중이라면 다음을 사용합니다.

chronyc tracking
chronyc sources -v

chronyc tracking은 질문에 대한 답이 되는 수치들을 출력합니다. System time는 NTP 시간과의 현재 오차이며, 뒤에 fast 또는 slow가 표시됩니다. Last offset는 가장 최근에 수행된 보정의 크기입니다. Frequency은 chrony가 측정하여 이미 보정 중인 시계의 오차율입니다. Leap status은 Normal로 표시되어야 합니다. 만약 Not synchronised로 표시되고 Reference ID이 00000000 ()이라면, chrony가 아직 동기화할 소스를 결정하지 못한 상태입니다.

chronyc sources -v는 목록 위에 범례를 출력하므로 기호를 외울 필요가 없습니다. 두 열이 핵심 정보를 담고 있습니다. 각 줄의 시작 부분에 있는 상태 문자는 chrony가 해당 소스를 평가하는 방식입니다. *은 현재 사용 중인 소스를 나타내며, 모든 줄에 ?가 표시된다면 응답하는 소스가 없다는 뜻입니다. Reach는 최근 8번의 폴링에 대한 응답 이력을 8진수로 출력합니다. 377은 8번 모두 응답했음을, 0은 한 번도 응답하지 않았음을 의미합니다.

systemd-timesyncd가 관리 중이라면 다음을 사용합니다.

timedatectl timesync-status
timedatectl show-timesync --all

timesync-status은 통신 중인 서버, 폴링 간격, 그리고 Offset 값을 출력합니다. 만약 상태를 출력하는 대신 서비스 관련 오류가 반환된다면, 이 머신은 timesyncd를 사용하지 않는 것이며 그 자체가 질문에 대한 답이 됩니다.

추가 도구 없이 외부와 대략적인 시간을 비교하려면 공용 HTTP Date 헤더를 확인하십시오. 이 헤더는 GMT 기준 1초 단위로 제공됩니다.

date -u
curl -sI https://www.cloudflare.com | grep -i '^date:'

1~2초 정도의 차이는 정상이며 아무런 문제가 없음을 의미합니다. 1분 이상의 차이가 난다면 그것은 해결해야 할 버그입니다.

VPS에서 chrony 또는 systemd-timesyncd 사용하기

Ubuntu와 Debian은 기본적으로 systemd-timesyncd를 제공합니다. 이는 SNTP(simple network time protocol) 클라이언트로, 한 번에 하나의 서버를 조회하여 시계를 해당 서버 시간에 맞게 조정합니다. 항상 온라인 상태를 유지하고 시작 시점의 시간이 대략적으로 정확한 시스템이라면 이것으로 충분하며, 실행 비용도 거의 들지 않습니다.

chrony는 완전한 NTP 구현체이며 가상 머신에서 더 나은 기본 선택지입니다. 그 이유는 chrony의 출력 결과에서 확인할 수 있습니다. chrony는 여러 소스를 동시에 폴링하여 일치하지 않는 소스를 폐기합니다. 또한 시스템 시계의 오차율을 측정하여 drift 파일에 기록하므로, 매 샘플을 쫓아가는 대신 시계의 오차 경향을 직접 보정합니다. 물리 서버와 달리 가상 머신에서 발생하는 두 가지 상황, 즉 호스트에 의해 일시 중지되거나 실행 중에 다른 호스트로 이동되는 상황에서도 빠르게 복구합니다. 호스트 PTP 장치가 제공될 때 이를 읽는 것도 chrony입니다.

sudo apt update && sudo apt install -y chrony
systemctl status chrony --no-pager
chronyc sources -v
chronyc tracking

설치 시 apt 출력 결과를 확인하십시오. Debian과 Ubuntu에서 chrony와 systemd-timesyncd 패키지는 모두 time-daemon을 제공하므로, apt는 chrony를 설치하면서 timesyncd를 제거합니다. 이는 올바른 동작이며 의도된 결과입니다. 두 데몬이 동시에 같은 시계를 설정하려고 하면 충돌이 발생하며, 그 과정에서 보고되는 오프셋은 신뢰할 수 없으므로 절대 두 데몬을 동시에 실행하지 마십시오. Rocky와 AlmaLinux에서는 sudo dnf install -y chrony로 설치하며, 이때 유닛 이름은 chrony가 아닌 chronyd입니다.

설정 파일은 Debian과 Ubuntu의 경우 /etc/chrony/chrony.conf이며, Rocky와 Alma의 경우 /etc/chrony.conf입니다. 배포판의 기본 설정은 이미 VPS에 적합하므로 특별한 이유가 없다면 변경하지 마십시오. 다음 두 가지 지시어는 이해해 둘 가치가 있습니다.

• pool 및 server 라인은 시간 소스를 지정합니다. iburst를 추가하면 chrony가 시작 시 빠른 버스트를 보내도록 지시하여, 첫 번째 동기화가 수 분이 아닌 수 초 내에 이루어집니다.
• makestep은 chrony가 시계를 서서히 조정할지 아니면 즉시 점프시킬지 결정합니다. grep -n makestep /etc/chrony/chrony.conf을 사용하여 현재 설정을 확인하십시오. Debian과 Ubuntu의 기본값인 makestep 1 3는 다음을 의미합니다. chronyd가 시작된 후 첫 세 번의 업데이트 동안, 오차가 1초 이상이면 시계를 즉시 조정(step)하고, 그 이후에는 서서히 조정(slew)합니다.

경로상의 변조를 방지하기 위해 시간 트래픽을 인증하려면 chrony 4 이상에서 지원하는 NTS(network time security)를 사용하십시오. 먼저 chronyd -v으로 버전을 확인하십시오. NTS를 사용하려면 UDP 123 포트뿐만 아니라 아웃바운드 TCP 4460 포트도 열려 있어야 합니다.

server time.cloudflare.com iburst nts

신뢰하기 전에 재시작하고 확인하십시오. 구문 분석에 실패한 설정은 시간 데몬을 전혀 남기지 않으며, 시계는 이를 알려주지 않습니다.

sudo systemctl restart chrony
chronyc sources -v
chronyc tracking

시간이 몇 분씩 틀린 시계가 계속 틀린 상태로 유지되는 이유

시간 데몬은 오프셋을 수정하는 두 가지 방법을 사용합니다. 슬루잉(slewing)은 오차가 사라질 때까지 시계 속도를 높이거나 낮추며, 이 방식은 시간을 계속 앞으로 흐르게 하여 타임스탬프가 반복되거나 건너뛰지 않게 합니다. 스테핑(stepping)은 즉시 정확한 값으로 점프하며, 이는 빠르지만 시계를 뒤로 돌릴 수도 있습니다. 벽시계의 시간을 기준으로 경과 시간을 측정하는 모든 작업에 있어 시간을 뒤로 돌리는 것은 위험하므로, 두 데몬 모두 슬루잉을 선호합니다.

이러한 선호 때문에 크게 틀어진 시계는 오랫동안 틀린 상태로 유지될 수 있습니다. chrony는 makestep가 허용하는 범위 내에서만 스테핑을 수행하며, 기본적으로 이는 데몬이 시작된 후 처음 몇 번의 업데이트 동안만 가능합니다. 일주일 동안 실행된 chronyd가 40초의 오차를 발견하면 이를 슬루잉으로 수정하려 하며, 40초를 슬루잉하는 데는 예상보다 훨씬 긴 시간이 걸립니다. 한가한 시간에 의도적으로 한 번 강제하십시오.

sudo chronyc makestep
chronyc tracking

이제 chronyc tracking는 System time 오프셋이 0에 가깝다고 보고해야 하며, Last offset은 방금 수정된 오차의 크기를 보여줄 것입니다. 시간이 항상 앞으로만 흐른다고 가정하는 소프트웨어는 시계가 뒤로 점프하면 혼란을 겪을 수 있으므로, 바쁜 데이터베이스 호스트에서 이 명령을 실행하기 전에 신중히 생각하십시오. 데몬을 재시작하는 것은 시작 시점에 makestep 범위가 다시 열리기 때문에 동일한 문제를 해결하는 더 부드러운 방법입니다.

컨테이너는 호스트의 시계를 공유합니다

컨테이너는 자체적인 벽시계(wall clock)를 가지고 있지 않으므로, 내부에서 동기화할 대상이 없습니다. Linux time namespace는 monotonic clock과 boot-time clock만 가상화합니다. CLOCK_REALTIME는 가상화되지 않으며, 이는 컨테이너가 실행 중인 호스트와 동일한 시스템 시계를 읽는다는 것을 의미합니다. 호스트의 시계를 수정하면 해당 호스트의 모든 컨테이너 시계가 즉시 수정됩니다.

이로 인해 몇 가지 결과가 발생합니다. 이미지 내부에 chrony나 ntpd를 설치하지 마십시오. 설치하더라도 아무런 효과가 없습니다. 권한이 없는(unprivileged) 컨테이너 내부에서 날짜를 설정하려고 하면 date: cannot set date: Operation not permitted 오류가 발생합니다. 커널은 해당 호출을 위해 CAP_SYS_TIME 권한을 요구하기 때문입니다. CAP_SYS_TIME 권한을 부여한다고 해서 컨테이너에 독립적인 시계가 생기는 것은 아닙니다. 오히려 컨테이너가 호스트의 시계를 변경할 수 있게 되어, 결과적으로 다른 모든 컨테이너의 시계까지 변경할 수 있게 됩니다.

컨테이너 내부의 시간대가 다른 것은 시계의 문제가 아닙니다. 자체적인 /etc/localtime을 포함하는 이미지는 동일한 시점을 다른 시간대 형식으로 출력할 뿐이므로, 시계는 정확하더라도 date는 잘못된 것처럼 보일 수 있습니다. 컨테이너 환경 변수에 TZ=UTC를 설정하면 이러한 혼란은 사라집니다. 선택한 런타임은 이 문제에 아무런 영향을 주지 않으며, rootless Podman과 Docker 비교 문서에서 런타임이 실제로 변경하는 내용을 다룹니다.

시간대: 서버는 UTC, 사용자는 현지 시간

서버의 시간대를 UTC로 설정하고 그대로 유지합니다.

timedatectl list-timezones | grep -i utc
sudo timedatectl set-timezone UTC
timedatectl

UTC는 일광 절약 시간제(Daylight Saving Time)를 적용하지 않으며, 이것이 UTC를 사용하는 주된 이유입니다. 일광 절약 시간제를 적용하는 시간대에서 오전 02:30에 실행되도록 설정된 일일 작업은 시계가 뒤로 조정되는 날에는 두 번 실행되고, 앞으로 조정되는 날에는 아예 실행되지 않습니다. man 8 cron은 3시간 미만의 시간 변화에 대한 특수 처리 방식을 설명합니다. 앞으로 조정되어 건너뛴 작업은 변경 직후에 실행되며, 뒤로 조정되어 반복되는 시간대에 포함된 작업은 두 번 실행되지 않습니다. 이러한 동작은 합리적이지만, 오전 03:00에 굳이 고민해야 할 문제는 아닙니다. UTC를 사용하면 작업은 1년 내내 매일 한 번씩만 실행됩니다. 작업이 이상한 시간에 실행되는 것이 아니라 아예 누락된다면, cron 작업이 조용히 실행되지 않는 이유를 확인하는 것이 더 적절합니다.

로그를 읽을 때도 같은 논리가 적용됩니다. journalctl은 시스템 시간대를 기준으로 타임스탬프를 표시하며, journalctl --utc은 UTC 사용을 강제합니다. 서로 다른 시간대에 있는 두 대의 서버를 운영하면 모든 사건을 시간 변환 과정으로 만들어 버리며, 압박을 받는 상황에서의 변환은 타임라인을 잘못 해석하는 원인이 됩니다. 시스템은 UTC로 유지하고 타임스탬프도 UTC로 저장하며, 사람이 읽는 시점에만 현지 시간으로 변환하십시오. 특정 명령에 대해 현지 시간으로 확인하고 싶다면 서버 설정을 변경하지 않고도 다음과 같이 확인할 수 있습니다.

TZ=Europe/Berlin date

timedatectl 출력의 한 줄이 이 섹션과 관련이 있습니다. RTC in local TZ은 no로 설정되어야 합니다. 이를 yes로 설정하는 것은 노트북에서 Windows와 듀얼 부팅을 할 때 사용하는 임시 방편일 뿐이며, 서버에서는 나중에 누군가 실수하게 만드는 오프셋을 추가할 뿐입니다. 이 설정이 활성화되면 timedatectl는 시스템이 RTC 시간을 현지 시간대로 읽도록 구성되었다는 경고를 출력합니다.

증상별 문제 해결

서버에서 2단계 인증 코드가 거부됩니다. 다른 것을 확인하기 전에 시스템 시계부터 확인하십시오. 인증 코드는 30초마다 증가하는 카운터를 기반으로 생성되므로, 서버 시간이 90초 늦다면 서버는 이미 휴대폰이 지나간 단계의 코드를 계산하게 됩니다. timedatectl 명령을 실행하면 System clock synchronized: no가 표시되거나, chronyc tracking 명령을 통해 큰 System time 오프셋을 확인할 수 있습니다. 이는 키 자체가 거부되는 문제와는 다르며, 키 거부 시에는 별도의 메시지가 출력됩니다. 이와 관련해서는 공개 키 인증 실패 가이드를 참조하십시오.

apt update 명령 실행 시 Release 파일이 아직 유효하지 않다는 메시지가 나옵니다. 전체 메시지에는 저장소 이름과 유효하지 않은 기간이 표시됩니다(예: is not valid yet (invalid for another 1d 2h 3min 4s)). 이는 서버 시계가 저장소의 Release 파일에 기록된 날짜보다 늦기 때문이며, 표시된 기간은 시계가 얼마나 뒤처져 있는지를 직접적으로 나타냅니다. 시스템 시계를 수정하십시오. 이 문제를 해결하려고 apt의 날짜 확인 기능을 비활성화해서는 안 됩니다. 해당 확인 기능은 오래된 패키지 인덱스를 제공하려는 공격을 방어하는 역할을 하기 때문입니다.

모든 소스 라인이 연결할 수 없는 상태로 표시되고 Reach 값이 0입니다. 응답이 없는 상태이므로 설정보다는 외부로 나가는 트래픽(egress)을 확인해야 합니다. NTP는 UDP 포트 123을 사용하며, 일부 네트워크에서는 이를 차단하거나 리다이렉트합니다. sudo chronyc ntpdata 명령은 Total TX 및 Total RX를 포함한 소스별 카운터를 출력합니다. 송신(TX) 카운트는 증가하는데 수신(RX) 카운트가 0이라면 패킷은 나가지만 응답이 돌아오지 않는 상황이며, 이는 서버와 소스 사이의 방화벽 문제일 가능성이 큽니다.

시계가 정상이었다가 갑자기 틀어졌습니다. 호스트 이벤트로 인해 발생할 수 있습니다. 스냅샷 복원, 게스트 일시 중지, 또는 다른 호스트로의 라이브 마이그레이션이 수행되면 게스트의 시간 인식이 실제 시간보다 뒤처질 수 있습니다. chrony는 다음 폴링 시점에 이를 감지하여 수정하지만, systemd-timesyncd는 긴 폴링 간격이 끝날 때까지 기다릴 수 있습니다. 데몬이 부팅 시 시작되는지 systemctl is-enabled chrony 명령으로 확인하십시오. 수동으로 시작한 데몬은 재부팅 후에는 실행되지 않기 때문입니다.

오프셋이 작지만 안정화되지 않습니다. CPU steal을 확인하십시오. 타이머 인터럽트가 발생해야 할 시점에 스케줄링되지 못한 게스트는 샘플링이 지연되므로, 오프셋이 수렴하지 않고 계속 변동합니다. top 명령을 실행하면 CPU 라인에서 st 수치를 확인할 수 있습니다. 공유 호스트에서 CPU steal time 읽기 문서에서 해당 수치의 의미와 대응 방법을 설명합니다.

방금 발급받은 인증서가 아직 유효하지 않다는 이유로 거부됩니다. curl 명령은 SSL certificate problem: certificate is not yet valid을 출력하며, 브라우저에서도 유사한 메시지가 나타납니다. 인증서 자체는 문제가 없으며, 이를 확인하는 시스템의 시계가 늦은 것입니다. 클라이언트와 서버 중 어느 쪽의 시계가 잘못되었을 수 있으므로 양쪽 모두 확인하십시오. 인증서를 발급한 서버의 시계가 잘못된 경우, certbot 및 nginx 인증서 가이드에서 갱신 관련 내용을 참조할 수 있습니다.

기존 점검 항목에 추가하기

시간 동기화는 부팅 시점에 설정되지만 수개월 뒤에 조용히 실패할 수 있습니다. 이는 사람이 기억에 의존하기보다 정기적인 점검으로 확인해야 하는 전형적인 항목입니다. timedatectl과 chronyc tracking를 확인하는 데는 2초면 충분합니다. 새 VPS 설정 후 첫 10분 작업 시 이 명령을 실행하고, 정기적인 Linux 서버 유지보수 체크리스트를 수행할 때 다시 확인하십시오. 점검을 자동화하고 시간 오차가 커질 때 알림을 받고 싶다면, systemd 서비스 및 타이머 작성에서 일정에 따라 보고하는 작은 유닛을 만드는 방법을 참조하십시오.

FAQ

VPS의 시계가 동기화되었는지 어떻게 확인합니까?

timedatectl을 실행하고 System clock synchronized 줄을 확인합니다. 이는 커널의 자체 플래그이며, 시계를 제어하는 데몬에 의해 설정됩니다. 따라서 chrony를 사용하는 시스템에서는 yes와 NTP service: n/a이 함께 표시되는 것이 정상이며 건강한 상태입니다. 오차 범위를 확인하려면 chronyc tracking를 실행하여 System time를 읽거나, systemd-timesyncd가 관리 중이라면 timedatectl timesync-status을 실행하여 Offset을 확인합니다. 외부 서버와 비교하려면 date -u의 결과와 임의의 HTTPS 사이트에서 반환하는 Date 헤더를 대조합니다.

VPS에서 chrony와 systemd-timesyncd 중 무엇을 사용해야 합니까?

중요한 서버라면 chrony를 사용하십시오. systemd-timesyncd는 하나의 서버를 따르는 SNTP 클라이언트이며, 항상 온라인 상태이고 초기 시간이 정확한 시스템에는 적합합니다. chrony는 여러 소스를 폴링하여 일치하지 않는 소스를 배제하고, 시계의 오차율을 학습하며, 호스트가 일시 중지되거나 라이브 마이그레이션이 발생한 후에도 빠르게 복구합니다. Debian이나 Ubuntu에 chrony를 설치하면 두 패키지 모두 time-daemon을 제공하므로 systemd-timesyncd가 자동으로 제거됩니다. 두 개의 시간 데몬을 동시에 실행하지 마십시오.

왜 특정 서버에서만 TOTP 코드가 실패하고 다른 곳에서는 잘 작동합니까?

TOTP 코드는 현재 시간에 의존하는 함수이기 때문입니다. 코드는 30초마다 증가하는 카운터에서 생성되므로, 서버와 휴대폰의 시간이 일치해야 합니다. 대부분의 인증기는 앞뒤로 한 단계(약 30초)의 오차를 허용합니다. 해당 서버에서 timedatectl을 확인하십시오. 만약 System clock synchronized가 no으로 표시된다면, 동기화를 수정하십시오. 공유 비밀 키를 변경할 필요 없이 코드가 다시 일치하게 됩니다.

Docker 컨테이너 내부의 시간을 설정할 수 있습니까?

아니요, 그럴 필요도 없습니다. 컨테이너는 호스트의 CLOCK_REALTIME를 공유합니다. Linux 시간 네임스페이스는 단조 시간(monotonic)과 부팅 시간(boot-time) 시계만 가상화하기 때문입니다. 권한이 없는 컨테이너는 date: cannot set date: Operation not permitted를 가지며, CAP_SYS_TIME을 추가하면 컨테이너가 자체 시계를 갖는 대신 호스트의 시계를 변경하게 됩니다. 호스트의 시간을 동기화하십시오. 컨테이너 내부의 다른 현지 시간은 시간대(time zone) 설정의 문제이므로, 컨테이너 환경에서 TZ을 설정하십시오.

서버는 UTC를 사용해야 합니까, 아니면 현지 시간을 사용해야 합니까?

UTC를 사용하고, 사람이 출력을 읽는 시점에 현지 시간을 적용하십시오. UTC는 일광 절약 시간제(daylight saving)에 따라 변경되지 않으므로, 일일 작업은 일 년 내내 하루에 한 번 실행되며 서로 다른 서버의 타임스탬프도 변환 없이 정렬됩니다. sudo timedatectl set-timezone UTC로 설정하십시오. 현지 시간을 확인하고 싶은 사람은 명령어 앞에 접두사를 붙이면 됩니다. 예를 들어 TZ=America/New_York date를 사용하면 시스템 시계에는 아무런 영향을 주지 않고 현지 시간을 확인할 수 있습니다.