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를 사용하지 않는 것이며 그 자체가 질문에 대한 답이 됩니다.

별도의 도구 없이 외부와 대략적인 시간을 비교하려면, 1초 단위의 해상도로 GMT 시간을 제공하는 공개 HTTP Date 헤더와 비교하십시오.

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은 즉시 정확한 값으로 점프하며, 이는 빠르지만 시계를 과거로 되돌릴 수도 있습니다. 벽시계를 기준으로 경과 시간을 측정하는 모든 작업에 있어 시간을 뒤로 돌리는 것은 위험하므로, 두 데몬 모두 slewing을 선호합니다.

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

sudo chronyc makestep
chronyc tracking

이제 chronyc tracking는 System time 오프셋이 0에 가깝다고 보고해야 하며, Last offset은 방금 수정된 오차의 크기를 보여주어야 합니다. 시간이 앞으로만 흐른다고 가정하는 소프트웨어는 시계가 뒤로 점프하면 오류를 일으킬 수 있으므로, 부하가 많은 데이터베이스 호스트에서 이 작업을 수행하기 전에 신중히 고려하십시오. 데몬을 재시작하는 것은 makestep 창이 시작 시점에 다시 열리기 때문에 동일한 문제를 해결하는 더 완만한 방법입니다.

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

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

이로 인해 몇 가지 결과가 발생합니다. 이미지 내부에 chrony나 ntpd를 설치하지 마십시오. 아무런 효과가 없기 때문입니다. 권한이 없는 컨테이너 내부에서 날짜를 설정하려고 하면 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를 포함한 소스별 카운터를 출력합니다. RX는 0인데 TX 카운트만 계속 증가한다면 패킷은 나가지만 응답이 돌아오지 않는 상황이며, 이는 서버와 소스 사이의 방화벽 문제일 가능성이 큽니다.

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

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

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

기존 점검 항목에 추가하기

시간 동기화는 부팅 시점에 설정되지만 몇 달 뒤에 조용히 실패할 수 있습니다. 이는 기억에 의존하지 않고 정기적인 점검을 통해 확인해야 하는 전형적인 문제입니다. timedatectl과 chronyc tracking를 확인하는 데는 2초면 충분합니다. 새로운 VPS를 설정하는 첫 10분 작업의 일부로 이 명령을 실행하고, 정기적인 Linux 서버 유지보수 체크리스트를 수행할 때 다시 확인하십시오. 점검이 자동으로 실행되고 시간 오차가 커질 때 알림을 받으려면, systemd 서비스 및 타이머 작성을 참고하여 정해진 일정에 따라 보고하는 작은 유닛을 구성하는 패턴을 익히십시오. 이러한 점검은 데몬이 아닌 짧은 스크립트 형태이므로 기본값 대신 Type=oneshot을 사용해야 합니다. 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 컨테이너 내부의 시간을 설정할 수 있습니까?

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

서버는 UTC와 로컬 시간 중 무엇을 사용해야 합니까?

UTC를 사용하고, 사람이 출력을 읽는 시점에 로컬 시간을 적용하십시오. UTC는 일광 절약 시간제에 따라 변경되지 않으므로 일일 작업이 일 년 내내 하루에 한 번 정확히 실행되며, 여러 서버의 타임스탬프를 변환 없이 정렬할 수 있습니다. sudo timedatectl set-timezone UTC로 설정하십시오. 로컬 시간으로 확인이 필요한 경우 명령어 앞에 TZ=America/New_York date과 같이 접두사를 붙여 실행하면 시스템 시계를 변경하지 않고도 로컬 시간을 확인할 수 있습니다.