VPS clock drift சரிசெய்வது எப்படி?

VPS clock ஏன் drift ஆகிறது

VPS clock-ஐ சரிசெய்யும் எந்த mechanism-மும் இயங்காததால் அது drift ஆகிறது. Kernel, சிறிது வேகமாக அல்லது மெதுவாக இயங்கும் hardware counter-இலிருந்து நேரத்தைக் கணக்கிடுகிறது. Time sync client இயங்கவில்லை என்றால், அந்தச் சிறிய பிழை ஒவ்வொரு மணி நேரமும் அதிகரிக்கும். Virtual machine-க்குள் இதற்கு இன்னொரு காரணமும் உள்ளது. உங்கள் guest, பிற guests-உடன் physical CPU-ஐப் பகிர்கிறது. எனவே அது schedule செய்யப்படாமல் இருக்கும் நேரத்தில் clock-ஐக் கணக்கிட முடியாது.

தற்போதைய KVM guest-ல் counter தானே பிரச்சினையாக இருப்பது அரிது. Paravirtual kvm-clock source, host பராமரிக்கும் மதிப்பைப் படிக்கிறது. எனவே ஆரோக்கியமான guest, அதன் host-ன் நேரத்தை நெருக்கமாகப் பின்பற்றும். வெளிப்படையாகத் தவறாகக் காட்டும் clocks, பொதுவாக இன்னும் சாதாரணமான காரணத்தால் தவறாக இருக்கும். எந்த sync daemon-மும் இயங்காமல் இருக்கலாம். அல்லது இரண்டு sync daemon-கள் இயங்கி ஒன்றுக்கொன்று முரண்படலாம். அல்லது outbound UDP port 123, உங்கள் provider-ன் network-ஐ விட்டு வெளியேறாமல் இருக்கலாம். Guest, தனது oscillator-இலிருந்து அல்ல; host அல்லது NTP (network time protocol)-இலிருந்து time discipline-ஐப் பெறுகிறது.

தவறான clock உண்மையில் எதைப் பாதிக்கிறது

• TOTP (time-based one-time password) two-factor codes பொருந்தாமல் போகும். இதனால் password மற்றும் cryptographic key இரண்டும் சரியாக இருந்தாலும் server-ல் இருந்து நீங்கள் lock out செய்யப்படுவீர்கள்.
• ஒரு நிமிடத்திற்கு முன் issue செய்யப்பட்ட certificate நிராகரிக்கப்படும்; curl, SSL certificate problem: certificate is not yet valid என்பதை print செய்யும்.
• apt update, E: Release file for ... is not valid yet (invalid for another 1d 2h 3min 4s) என்ற காரணத்துடன் repository-ஐ நிராகரிக்கும்.
• Scheduled work தவறான நேரத்தில் இயங்கும். clock தாவும்போது, ஒரு job இரண்டு முறை இயங்கியும் மற்றொரு job skip ஆகியும் இருக்கலாம்.
• இரண்டு server-களிலிருந்து வரும் logs-ஐ ஒரே timeline-ல் பொருத்த முடியாது. எனவே incident timeline-ஐ ஊகத்தின் அடிப்படையில் தொகுக்க வேண்டியிருக்கும்.

பெரும்பாலானவர்கள் எதிர்பார்ப்பதைவிட இந்த tolerance குறைவாக உள்ளது. கீழே உள்ள மதிப்புகள் documented defaults; test மூலம் அளந்தவை அல்ல.

[
  {
    "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 code, ஒவ்வொரு 30 seconds-க்கும் முன்னேறும் counter-ஐ அடிப்படையாகக் கொண்டு கணக்கிடப்படுகிறது. பெரும்பாலான verifiers, அதற்கு முன் அல்லது பின் உள்ள ஒரு step-ஐ ஏற்றுக்கொள்கின்றன. ஒவ்வொரு திசையிலும் அரை நிமிட clock error மட்டுமே முழு allowance ஆகும். Kerberos இதைவிட அதிக tolerance கொண்டது. இதன் default skew allowance 300 seconds ஆகும். Certificate-க்கு tolerance இல்லை. அது fixed instants-க்கு எதிராகச் சரிபார்க்கப்படுகிறது; grace period 0 seconds மட்டுமே. எனவே clock ஒரு second முன்னதாக இருந்தாலும், சரியாக valid-ஆக இருக்கும் certificate நிராகரிக்கப்படும்.

மூன்று clocks, அவற்றில் முக்கியமானது எது

System clock தான் முக்கியமானது. இது kernel-ன் CLOCK_REALTIME ஆகும்: 1 January 1970 UTC முதல் கடந்த seconds-ன் எண்ணிக்கை. இது memory-ல் வைக்கப்பட்டு, நேரத்தைப் பதிவு செய்யும் அனைத்தாலும் வாசிக்கப்படுகிறது. Log lines, certificate checks, TOTP codes மற்றும் file modification times ஆகிய அனைத்தும் இதிலிருந்தே பெறப்படுகின்றன. Server-ன் time தவறாக உள்ளது என்று ஒருவர் கூறும்போது, அவர் குறிப்பிடுவது இந்த clock-ஐத்தான்.

Hardware clock, RTC (real time clock) என்றும் அழைக்கப்படுகிறது. Machine off நிலையில் இருந்தாலும் தொடர்ந்து இயங்கும் தனி counter இதுவாகும். Physical machine-ல் இது battery-backed chip ஆக இருக்கும். Guest-க்குள் இதை hypervisor emulation செய்கிறது; எனவே இது பெரும்பாலும் host சார்ந்ததாகும். Linux, boot நேரத்தில் தொடக்க மதிப்பைப் பெற இதை ஒருமுறை வாசிக்கிறது; அதன் பிறகு தனக்கான count-ஐத் தொடர்கிறது. timedatectl இதை RTC time line-ல் காட்டுகிறது. VPS-ல் அந்த line-ஐ அடிப்படையாகக் கொண்டு debug செய்ய வேண்டாம். ஏனெனில் அது உங்கள் system clock-ன் sync state-ஐ அல்ல, host-ன் time குறித்த மதிப்பீட்டையே காட்டுகிறது. Container-ல் பொதுவாக /dev/rtc இருப்பதில்லை. எனவே hwclock --show, hwclock: Cannot access the Hardware Clock via any known method. உடன் fail ஆகிறது.

Clocksource என்பது அந்த reads-க்கு இடையில் kernel count செய்யப் பயன்படுத்தும் source ஆகும். உங்கள் kernel தேர்ந்தெடுத்த source எது என்பதைப் பார்க்கவும்:

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

KVM-ல் பொதுவாக kvm-clock என்பதைக் காண்பீர்கள். இது host பராமரிக்கும் value-ஐ வாசிக்கிறது. அதனால் NTP client இல்லாத KVM guest கூட சில நேரம் தோராயமாக சரியான time-ல் இருக்கும். tsc என்பது CPU-ன் சொந்த counter ஆகும். Xen guests xen-ஐ report செய்கின்றன; Hyper-V guests, hyperv source-ஐ report செய்கின்றன. இந்த setting-ஐ மாற்றுவதற்கு measured காரணம் இல்லையெனில் அப்படியே விடவும். ஏனெனில் அந்த hardware-ல் kernel நம்பகமான சிறந்த source-ஐ ஏற்கனவே தேர்ந்தெடுக்கிறது.

சில hosts, PTP (precision time protocol) device-ஐ guest-க்கு வழங்குகின்றன. இதனால் chrony, network வழியாக அல்லாமல் host clock-ஐ நேரடியாக வாசிக்க முடியும். இதைச் சரிபார்ப்பது பயனுள்ளதாகும். ஆனால் shared VPS-ல் இது பெரும்பாலும் கிடைக்காது:

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

modprobe fail ஆனால் device எதுவும் தோன்றவில்லை என்றால், உங்கள் host இதை வழங்கவில்லை. அந்நிலையில் network NTP தான் பயன்படுத்த வேண்டிய வழி. clock_name, KVM virtual clock-ஐக் குறிப்பிடுமானால், chrony தனது config-ல் உள்ள refclock PHC /dev/ptp0 poll 2 line மூலம் அதைப் பயன்படுத்த முடியும்.

உங்கள் சொந்த machine-ன் time state-ஐப் பார்க்கவும்

ஒரே command-இல் தொடங்கவும். இந்த clock-ஐ சரியாக வைத்திருக்க ஏதேனும் செயல்படுகிறதா என்பதை அது ஒரே திரையில் காட்டும்.

timedatectl

நினைவில் வைத்துள்ள எண்ணை நம்புவதற்குப் பதிலாக, இந்த lines-ஐப் படிக்கவும்:

• Local time மற்றும் Universal time ஆகியவை ஒரே instant-ஐ உங்கள் zone-லும் UTC-யிலும் காட்டுகின்றன. அவை ஒரே மாதிரியாக இருந்தால், machine ஏற்கனவே UTC-ஐப் பயன்படுத்துகிறது.
• RTC time என்பது மேலே விளக்கப்பட்ட hardware clock. VPS-ல் இதைப் புறக்கணிக்கவும்.
• Time zone என்பது local time-ஐ format செய்ய system பயன்படுத்துவது.
• System clock synchronized என்பது kernel-ன் சொந்த flag. Time daemon தனது sources மீது நம்பிக்கை ஏற்பட்டதும் இதை அமைக்கும். எனவே no என்றால், boot-க்கு பிறகு இந்த clock-ஐ எந்த daemon-மும் discipline செய்யவில்லை.
• NTP service என்பது systemd-timesyncd பற்றிய நிலையை மட்டும் காட்டுகிறது. chrony இயங்கும் machine-ல் n/a என்பது இயல்பானது, ஏனெனில் அங்கு timesyncd நிறுவப்பட்டிருக்காது. System clock synchronized: yes உடன் NTP service: n/a காணப்பட்டால், chrony இந்தப் பணியைச் செய்கிறது என்றும் kernel அதனுடன் ஒத்துப்போகிறது என்றும் பொருள்.

அடுத்து, உங்கள் clock எவ்வளவு விலகியுள்ளது என்பதைப் பார்க்கவும். அதை உங்கள் phone-ஐ வைத்து கணிப்பாக ஒப்பிட வேண்டாம். chrony இயங்கினால்:

chronyc tracking
chronyc sources -v

இந்தக் கேள்விக்கு தேவையான numbers-ஐ chronyc tracking அச்சிடும். System time என்பது NTP time-இலிருந்து தற்போதைய offset. அதன் பின் fast அல்லது slow என்ற word வரும். Last offset என்பது சமீபத்திய correction-ன் அளவு. Frequency என்பது உங்கள் clock-ல் chrony அளந்த rate error; அதற்காக chrony ஏற்கனவே compensation செய்கிறது. Leap status என்பது Normal என்று காட்ட வேண்டும். அது Not synchronised என்றும் Reference ID என்பது 00000000 () என்றும் காட்டினால், chrony இன்னும் ஒரு source-ஐத் தேர்ந்தெடுத்து நிலைநிறுத்தவில்லை.

chronyc sources -v list-க்கு மேலே ஒரு legend-ஐ அச்சிடும். எனவே symbols-ஐ நினைவில் வைத்திருக்க வேண்டியதில்லை. பெரும்பாலான பொருளை இரண்டு columns காட்டுகின்றன. ஒவ்வொரு line-ன் தொடக்கத்தில் உள்ள state character-ஐ வைத்து, அந்த source-ஐ chrony மதிப்பிடுகிறது. இதில் * தற்போது பயன்படுத்தப்படும் source-ஐக் குறிக்கும்; ஒவ்வொரு line-லும் ? இருந்தால், எந்த source-மும் பதிலளிக்கவில்லை என்று பொருள். Reach என்பது கடந்த எட்டு polls-ன் reply history-ஐ octal வடிவில் காட்டுகிறது: 377 என்றால் எட்டுக்கும் பதில் கிடைத்தது; 0 என்றால் எதற்கும் பதில் கிடைக்கவில்லை.

systemd-timesyncd பொறுப்பில் இருந்தால்:

timedatectl timesync-status
timedatectl show-timesync --all

அது தொடர்புகொள்ளும் server, poll interval மற்றும் Offset value-ஐ timesync-status அச்சிடும். status-ஐ அச்சிடுவதற்குப் பதிலாக service பற்றிய error-ஐ command திருப்பி அளித்தால், இந்த machine-ல் timesyncd daemon பொறுப்பில் இல்லை. அதுவே உங்கள் கேள்விக்கான பதிலும் ஆகும்.

கூடுதல் tools இல்லாமல் வெளிப்புற உலகத்துடன் rough check செய்ய, public HTTP Date header-ஐ வைத்து உங்கள் clock-ஐ ஒப்பிடலாம். இது GMT-ல், one second resolution-உடன் வழங்கப்படுகிறது:

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

இங்கே one அல்லது two seconds வித்தியாசம் இருப்பது இயல்பானது; அதற்கு முக்கியத்துவம் இல்லை. one minute வித்தியாசம் இருந்தால், அது உங்கள் bug.

VPS-ல் chrony அல்லது systemd-timesyncd

Ubuntu மற்றும் Debian ஆகியவை இயல்பாக systemd-timesyncd-ஐ வழங்குகின்றன. இது SNTP (simple network time protocol) client ஆகும். இது ஒரே நேரத்தில் ஒரு server-ஐ query செய்து, அதன் நேரத்தை நோக்கி system clock-ஐச் சிறிதளவு சரிசெய்கிறது. எப்போதும் online-ல் இருக்கும் மற்றும் தொடக்கத்திலேயே தோராயமாகச் சரியான நேரத்தைக் கொண்ட machine-க்கு இது போதுமானது. இதை இயக்குவதற்கான செலவும் மிகக் குறைவு.

chrony என்பது முழுமையான NTP implementation ஆகும். Virtual machine-க்கு இது சிறந்த default ஆகும். இதற்கான காரணங்களை அதன் சொந்த output-ல் காணலாம். இது ஒரே நேரத்தில் பல sources-ஐ poll செய்து, ஒன்றுக்கொன்று முரண்படும் sources-ஐ நீக்குகிறது. உங்கள் clock-ன் rate error-ஐ அளந்து, அதை drift file-ல் எழுதுகிறது. இதனால் ஒவ்வொரு sample-ஐத் தொடர்ந்து clock-ஐ மாற்றுவதற்குப் பதிலாக, clock-ன் இயல்பான விலகலைச் சரிசெய்கிறது. Physical box-ல் இல்லாத இரண்டு நிலைகளிலிருந்தும் VM விரைவாக மீள chrony உதவுகிறது: host VM-ஐ pause செய்யலாம்; இயங்கிக்கொண்டிருக்கும்போதே VM-ஐ வேறு host-க்கு move செய்யலாம். Host PTP device வழங்கப்பட்டால், அதை வாசிப்பது chrony ஆகும்.

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

apt இயங்கும்போது அதன் output-ஐப் படிக்கவும். Debian மற்றும் Ubuntu-ல் chrony மற்றும் systemd-timesyncd packages இரண்டும் time-daemon-ஐ வழங்குகின்றன. எனவே chrony-ஐ install செய்யும்போது apt timesyncd-ஐ remove செய்கிறது. இது சரியானதும் எதிர்பார்க்கப்பட்டதுமாகும். இரண்டையும் ஒருபோதும் இயக்க வேண்டாம். ஒரே clock-ஐ அமைக்க முயலும் இரண்டு daemons ஒன்றுக்கொன்று முரண்படும். அவை இயங்கிக்கொண்டிருக்கும்போது, எந்த daemon-ன் reported offset-ஐயும் நம்ப முடியாது. Rocky மற்றும் AlmaLinux-ல் sudo dnf install -y chrony மூலம் install செய்யவும். அங்கு unit-ன் பெயர் chrony என்பதற்குப் பதிலாக chronyd ஆகும்.

Debian மற்றும் Ubuntu-ல் config file /etc/chrony/chrony.conf ஆகும். Rocky மற்றும் Alma-ல் அது /etc/chrony.conf ஆகும். Distribution default ஏற்கனவே VPS-க்கு ஏற்றதாக உள்ளது. எனவே குறிப்பிட்ட காரணம் இருந்தால் மட்டுமே அதை மாற்றவும். இரண்டு directives-ஐப் புரிந்துகொள்வது பயனுள்ளதாகும்:

• pool மற்றும் server lines time sources-ன் பெயர்களைக் குறிப்பிடுகின்றன. iburst-ஐச் சேர்த்தால், startup-இல் chrony வேகமான burst-ஐ அனுப்பும். இதனால் முதல் sync minutes-ல் அல்லாமல் seconds-ல் நடைபெறும்.
• chrony clock-ஐ மெதுவாகச் சரிசெய்வதற்குப் பதிலாக எப்போது jump செய்ய வேண்டும் என்பதை makestep தீர்மானிக்கிறது. உங்கள் அமைப்பில் அது என்ன மதிப்பைக் கொண்டுள்ளது என்பதை grep -n makestep /etc/chrony/chrony.conf மூலம் பார்க்கவும். Debian மற்றும் Ubuntu-ன் default ஆன makestep 1 3 என்பதன் பொருள் இதுதான்: chronyd தொடங்கிய பிறகு நடைபெறும் முதல் மூன்று updates-ல், clock ஒரு second-க்கும் அதிகமாக விலகியிருந்தால் அதை step செய்யும். அதன் பிறகு, slew செய்வதன் மூலம் மட்டுமே correction செய்யும்.

Path-ல் நடைபெறும் tampering-க்கு எதிராக time traffic authenticated ஆக வேண்டும் என்றால், chrony 4 மற்றும் அதற்குப் பிந்தைய versions NTS (network time security)-ஐ ஆதரிக்கின்றன. முதலில் உங்கள் version-ஐ chronyd -v மூலம் உறுதிப்படுத்தவும். NTS-க்கு UDP 123 மட்டுமின்றி outbound TCP port 4460-மும் திறந்திருக்க வேண்டும் என்பதை நினைவில் கொள்ளவும்:

server time.cloudflare.com iburst nts

அதை நம்புவதற்கு முன் restart செய்து verify செய்யவும். Config parse ஆகவில்லை என்றால், எந்த time daemon-மும் இயங்காமல் போகும். இதை clock தானாகத் தெரிவிக்காது.

sudo systemctl restart chrony
chronyc sources -v
chronyc tracking

சில நிமிடங்கள் தவறாக இருக்கும் clock ஏன் தொடர்ந்து தவறாகவே இருக்கும்

ஒரு time daemon-க்கு offset-ஐ சரிசெய்ய இரண்டு வழிகள் உள்ளன. Slewing என்பது பிழை நீங்கும் வரை clock-ன் வேகத்தை அதிகரிப்பது அல்லது குறைப்பது. இதனால் time தொடர்ந்து முன்னோக்கி நகரும்; எந்த timestamp-உம் மீண்டும் வராது அல்லது தவிர்க்கப்படாது. Stepping என்பது சரியான மதிப்புக்கு clock-ஐ நேரடியாக மாற்றுவது. இது வேகமானது; ஆனால் clock-ஐ பின்னோக்கியும் நகர்த்தலாம். Wall clock-ஐ அடிப்படையாகக் கொண்டு elapsed time-ஐ அளக்கும் எந்த software-க்கும் பின்னோக்கி நகரும் நேரம் ஆபத்தானது. எனவே இரண்டு daemons-உம் பொதுவாக slew செய்ய விரும்புகின்றன.

இதனால் மிகவும் தவறாக இருக்கும் clock நீண்ட நேரம் தவறாகவே இருக்கலாம். chrony, makestep அனுமதிக்கும் window-க்குள் மட்டுமே step செய்கிறது. இயல்புநிலையில், daemon தொடங்கிய பிறகு பெறப்படும் முதல் சில updates-க்கு மட்டுமே இந்த window இருக்கும். ஒரு வாரமாக இயங்கி வந்த chronyd, பின்னர் forty second பிழையைக் கண்டறிந்தால், அதை slew செய்யும். ஆனால் forty seconds-ஐ slew செய்ய நீங்கள் காத்திருக்க விரும்பும் நேரத்தை விட அதிக நேரம் தேவைப்படும். அமைதியான நேரத்தில், ஒருமுறை இதை திட்டமிட்டு force செய்யவும்:

sudo chronyc makestep
chronyc tracking

chronyc tracking இப்போது near zero ஆக இருக்கும் System time offset-ஐ report செய்ய வேண்டும். இப்போது சரிசெய்யப்பட்ட அளவை Last offset காட்ட வேண்டும். Busy database host-ல் இதை இயக்குவதற்கு முன் சிந்திக்கவும். ஏனெனில் பின்னோக்கி jump செய்யும் clock, time எப்போதும் முன்னோக்கி மட்டுமே நகரும் என்று கருதிய software-ஐ குழப்பக்கூடும். daemon-ஐ restart செய்வது இதே fix-ன் மென்மையான முறையாகும். காரணம், start நேரத்தில் makestep window மீண்டும் திறக்கிறது.

Containers host-ன் clock-ஐ பகிர்கின்றன

ஒரு container-க்கு தனிப்பட்ட wall clock இல்லை. எனவே அதற்குள் sync செய்ய வேண்டிய clock எதுவும் இல்லை. Linux time namespaces, monotonic மற்றும் boot-time clocks-ஐ மட்டுமே virtualise செய்கின்றன. CLOCK_REALTIME virtualise செய்யப்படாது. இதனால் container இயங்கும் host-ன் அதே system clock-ஐ அது வாசிக்கிறது. Host-ல் clock-ஐ சரிசெய்தால், அந்த host-ல் இயங்கும் ஒவ்வொரு container-லும் அதே நேரத்தில் சரியாகிவிடும்.

இதனால் சில விளைவுகள் ஏற்படும். Image-ல் chrony அல்லது ntpd-ஐ install செய்ய வேண்டாம். அதிகபட்சம் அது எந்தப் பயனும் அளிக்காது. Privileged அல்லாத container-ல் date-ஐ அமைக்க முயன்றால் date: cannot set date: Operation not permitted ஏற்படும். அந்த system call-க்கு kernel-க்கு CAP_SYS_TIME தேவைப்படுவதால் இது நிகழ்கிறது. CAP_SYS_TIME வழங்கினாலும் container-க்கு தனிப்பட்ட clock கிடைக்காது. அதற்கு பதிலாக host-ன் clock-ஐ மாற்றும் திறன் கிடைக்கும். இதனால் மற்ற எல்லா container-களின் clock-களும் மாறும்.

Container-க்குள் வேறுபட்ட time zone இருப்பது clock பிரச்சினை அல்ல. தனக்கான /etc/localtime கொண்ட image, அதே instant-ஐ மற்றொரு zone-க்கு ஏற்ப format செய்து காட்டும். எனவே date தவறாகத் தோன்றலாம்; clock சரியாகவே இருக்கும். Container environment-ல் TZ=UTC-ஐ அமைத்தால் இந்தக் குழப்பம் நீங்கும். நீங்கள் தேர்ந்தெடுத்த runtime இதைப் பற்றி எந்த மாற்றமும் செய்யாது. அது மாற்றும் அம்சங்கள் குறித்து rootless Podman மற்றும் Docker ஒப்பீடு விளக்குகிறது.

Time zones: server-க்கு UTC, மனிதர்களுக்கு local time

Machine-ஐ UTC-க்கு அமைத்து அதிலேயே வைத்திருக்கவும்.

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

UTC-யில் daylight saving இல்லை. இதுவே முக்கிய காரணம். daylight saving பயன்படுத்தும் ஒரு time zone-ல் 02:30-க்கு அமைக்கப்பட்ட daily job, clocks பின்னோக்கி மாற்றப்படும் நாளில் இரண்டு முறை இயங்கும்; clocks முன்னோக்கி மாற்றப்படும் நாளில் இயங்கவே இயங்காது. மூன்று மணி நேரத்திற்குக் குறைவான shifts-க்கான சிறப்பு handling-ஐ man 8 cron ஆவணப்படுத்துகிறது: forward jump காரணமாக தவறிய jobs, மாற்றத்திற்குப் பிறகு விரைவில் இயக்கப்படும்; backward jump காரணமாக மீண்டும் தோன்றும் ஒரு மணி நேரத்துக்குள் சிக்கிய jobs, இரண்டாவது முறை இயக்கப்படாது. இந்த நடத்தை நியாயமானது. இருந்தாலும் 03:00 மணிக்கு இதைப் பற்றி நீங்கள் கணக்கிட வேண்டிய நிலை இருக்கக்கூடாது. UTC-யில் அந்த job ஆண்டின் ஒவ்வொரு நாளும் ஒருமுறை இயங்கும். உங்கள் job ஒன்று விசித்திரமான நேரத்தில் இயங்குவதற்குப் பதிலாக முற்றிலும் காணாமல் போயிருந்தால், cron job இயங்காமல் இருப்பதற்கான காரணங்கள் என்பதே அதிகம் சாத்தியமான விளக்கம்.

Logs-ஐப் படிப்பதற்கும் இதே காரணம் பொருந்தும். journalctl timestamps-ஐ system time zone-ல் format செய்கிறது; journalctl --utc UTC-ஐ கட்டாயப்படுத்துகிறது. வெவ்வேறு zones-ல் உள்ள இரண்டு servers, ஒவ்வொரு incident-ஐயும் time conversion செய்ய வேண்டிய நிலையாக மாற்றும். அழுத்தமான சூழலில் செய்யப்படும் conversions காரணமாக timeline-ஐ மக்கள் தவறாகப் புரிந்துகொள்வார்கள். Systems-ஐ UTC-யில் வைத்திருங்கள்; timestamps-ஐ UTC-யில் சேமியுங்கள்; மனிதர் படிக்கும் இடத்தில் மட்டும் ஒருமுறை local time-ஆக மாற்றுங்கள். ஒரு command-க்கு மட்டும் local time தேவைப்பட்டால், machine-ன் time zone-ஐ மாற்றாமல் அதைக் கேட்கலாம்:

TZ=Europe/Berlin date

timedatectl output-ல் உள்ள மேலும் ஒரு line இந்த section-க்கு உட்பட்டது. RTC in local TZ என்பது no ஆக இருக்க வேண்டும். Laptop-ல் Windows உடன் dual-boot செய்வதற்கான workaround ஆக இதை yes-ஆக அமைக்கலாம். Server-ல் இது பின்னர் யாராவது தவறாகப் பயன்படுத்தக்கூடிய ஒரு offset-ஐ மட்டுமே சேர்க்கும். இது set செய்யப்பட்டிருக்கும்போது, RTC time-ஐ local time zone-ல் படிக்க system configure செய்யப்பட்டுள்ளதாக timedatectl ஒரு warning-ஐ அச்சிடும்.

அறிகுறி அடிப்படையிலான சிக்கல் தீர்வு

ஒரு server-ல் two-factor code நிராகரிக்கப்படுகிறது. வேறு எதையும் சரிபார்ப்பதற்கு முன் clock-ஐ சரிபார்க்கவும். இந்த code, ஒவ்வொரு 30 seconds-க்கும் முன்னேறும் counter-இலிருந்து உருவாகிறது. ஆகவே, 90 seconds பின்னால் இருக்கும் server, உங்கள் phone ஏற்கனவே கடந்து சென்ற step-க்கான code-ஐ கணக்கிடும். timedatectl, System clock synchronized: no-ஐ காட்டும்; அல்லது chronyc tracking பெரிய System time offset-ஐ தெரிவிக்கும். இது key முற்றிலும் நிராகரிக்கப்படும் பிரச்சினையிலிருந்து வேறுபட்டது. அந்த நிலைக்கு தனியான message அச்சிடப்படும். அதற்கான விளக்கம் publickey authentication தோல்விகளுக்கான வழிகாட்டி-ல் உள்ளது.

apt update, Release file இன்னும் valid இல்லை என்று தெரிவிக்கிறது. முழு message repository-யின் பெயரையும் அது எவ்வளவு நேரம் invalid நிலையில் இருக்கும் என்பதையும் குறிப்பிடும். எடுத்துக்காட்டாக, is not valid yet (invalid for another 1d 2h 3min 4s). உங்கள் clock, repository-யின் Release file-ல் உள்ள date-ஐ விட பின்னால் உள்ளது. குறிப்பிடப்பட்ட duration, clock எவ்வளவு பின்னால் உள்ளது என்பதற்கான நேரடி அளவாகும். Clock-ஐ சரிசெய்யவும். இதைத் தவிர்க்க apt-ன் date check-ஐ disable செய்ய வேண்டாம். ஏனெனில், stale package index உங்களுக்கு வழங்கப்படுவதைத் தடுப்பது அந்த check தான்.

ஒவ்வொரு source line-மும் unreachable நிலையை காட்டுகிறது; Reach 0 ஆக உள்ளது. எந்த பதிலும் வரவில்லை. எனவே உங்கள் config-ஐ விட egress-ஐச் சரிபார்க்கவும். NTP, outbound UDP port 123-ஐப் பயன்படுத்துகிறது. சில networks இதை filter அல்லது redirect செய்யலாம். sudo chronyc ntpdata, Total TX மற்றும் Total RX உட்பட ஒவ்வொரு source-க்குமான counters-ஐ அச்சிடும். RX 0-ஆக இருக்கும்போது TX count அதிகரித்தால், உங்கள் packets வெளியே செல்கின்றன; ஆனால் பதில் எதுவும் திரும்பவில்லை. இது உங்களுக்கும் source-க்கும் இடையில் உள்ள firewall-ஐக் குறிக்கிறது.

Clock சரியாக இருந்தது; பின்னர் திடீரென மாறியது. Host events இதை ஏற்படுத்தலாம். Restored snapshot, paused guest, அல்லது வேறு host-க்கு செய்யப்பட்ட live migration ஆகியவை guest-ன் time கணிப்பை உண்மையான நேரத்திற்குப் பின்னால் விட்டுவிடலாம். அடுத்த poll-ல் chrony இதைக் கண்டறிந்து சரிசெய்யும். systemd-timesyncd முதலில் நீண்ட poll interval முடியும் வரை காத்திருக்கலாம். systemctl is-enabled chrony மூலம் daemon boot நேரத்தில் தொடங்குகிறதா என்பதை உறுதிப்படுத்தவும். கையால் தொடங்கப்பட்ட daemon அடுத்த reboot-க்கு பிறகு இயங்காது.

Offset சிறியதாக உள்ளது; ஆனால் ஒருபோதும் நிலைபெறவில்லை. CPU steal-ஐப் பார்க்கவும். Timer interrupt வரவேண்டிய நேரத்தில் schedule செய்யப்படாத guest-ன் samples தாமதமாகக் கிடைக்கும். எனவே offset நிலைபெறாமல் மாறிக்கொண்டே இருக்கும். CPU line-ல் உள்ள st figure மூலம் இதை top காட்டும். shared host-ல் CPU steal time-ஐப் படித்தல் அந்த எண்ணின் பொருளையும், இதைச் சரிசெய்ய நீங்கள் செய்யக்கூடியவற்றையும் விளக்குகிறது.

இப்போதுதான் issue செய்த certificate, not yet valid என நிராகரிக்கப்படுகிறது. curl, SSL certificate problem: certificate is not yet valid-ஐ அச்சிடும். Browsers-லும் இதற்கு ஒத்த message தோன்றும். Certificate சரியாக உள்ளது; அதைச் சரிபார்க்கும் clock பின்னால் உள்ளது. பிரச்சினைக்குக் காரணமானது client அல்லது server என எதுவாகவும் இருக்கலாம். எனவே இரண்டையும் சரிபார்க்கவும். Certificate-ஐ issue செய்த server-ன் clock தவறாக இருந்தால், அதே setup-ன் renewal பகுதியை certbot மற்றும் nginx certificate வழிகாட்டி விளக்குகிறது.

ஏற்கனவே இயக்கும் சோதனைகளுடன் இதையும் சேர்க்கவும்

Time sync என்பது boot-time அமைப்பாகும். இது பல மாதங்களுக்குப் பிறகு எந்தப் பிழைச் செய்தியும் இல்லாமல் தோல்வியடையலாம். இதுபோன்ற பிரச்சினையை routine check கண்டறியும்; நினைவில் வைத்திருப்பது கண்டறியாது. timedatectl மற்றும் chronyc tracking ஆகியவற்றை ஒன்றாகப் படிக்க இரண்டு விநாடிகள் போதும். புதிய VPS-ல் முதல் பத்து நிமிடங்களில் இதைச் சோதனைகளின் ஒரு பகுதியாக இயக்கவும். பின்னர் வழக்கமான Linux server maintenance checklist-ஐப் பின்பற்றும்போதும் மீண்டும் இயக்கவும். Offset அதிகரிக்கும்போது check தானாக இயங்கி எச்சரிக்கை வழங்க வேண்டும் என்றால், systemd service மற்றும் timer எழுதுதல் சிறிய unit ஒன்று குறிப்பிட்ட schedule-ல் report செய்யும் முறையை விளக்குகிறது. இதுபோன்ற check daemon அல்ல; இது ஒரு short script. எனவே default-க்குப் பதிலாக Type=oneshot தேவைப்படுகிறது. தவறான வகையைத் தேர்ந்தெடுத்தால், பெறாத வெற்றியைப் பெற்றதாக report செய்யும் unit உருவாகும் என்பதற்கான காரணத்தை systemd service types பற்றிய விளக்கம் கூறுகிறது.

FAQ

VPS-ன் clock sync-ல் உள்ளதா என்பதை எவ்வாறு சரிபார்ப்பது?

timedatectl-ஐ இயக்கி, System clock synchronized line-ஐப் படிக்கவும். இது clock-ஐ கட்டுப்படுத்தும் daemon அமைக்கும் kernel-ன் சொந்த flag ஆகும். எனவே chrony இயங்கும் machine-ல் yes மற்றும் NTP service: n/a இருப்பது இயல்பானதும் சரியானதுமாகும். பிழையின் அளவை அறிய chronyc tracking-ஐ இயக்கி System time-ஐப் படிக்கவும். systemd-timesyncd பொறுப்பில் இருந்தால், timedatectl timesync-status-ஐ இயக்கி Offset-ஐப் படிக்கவும். Machine-க்கு வெளியிலுள்ள source-ஐ வைத்து சரிபார்க்க, date -u-ஐ எந்த HTTPS site-மும் திருப்பி அனுப்பும் Date header-உடன் ஒப்பிடவும்.

VPS-ல் chrony அல்லது systemd-timesyncd-ஐ பயன்படுத்த வேண்டுமா?

முக்கியமான எந்த server-லும் chrony-ஐப் பயன்படுத்தவும். systemd-timesyncd என்பது ஒரே server-ஐப் பின்பற்றும் SNTP client ஆகும். எப்போதும் online-ல் இருந்து, தொடக்கத்திலேயே சரியான நேரத்திற்கு அருகில் இருக்கும் machine-க்கு அது போதுமானது. chrony பல sources-ஐ poll செய்து, ஒன்றுக்கொன்று முரண்படும் sources-ஐ நிராகரிக்கும். உங்கள் clock-ன் rate error-ஐ அது கற்றுக்கொண்டு, host pause அல்லது live migration ஏற்பட்ட பிறகு விரைவாகச் சரியாகும். Debian அல்லது Ubuntu-ல் chrony-ஐ நிறுவினால் systemd-timesyncd தானாக அகற்றப்படும். இரண்டு packages-உம் time-daemon-ஐ வழங்குவதால் இது நிகழ்கிறது. ஒரே நேரத்தில் இரண்டு time daemon-களை இயக்க வேண்டாம்.

ஒரு server-ல் TOTP codes தோல்வியடைந்து, மற்ற இடங்களில் செயல்படுவது ஏன்?

TOTP code தற்போதைய நேரத்தை அடிப்படையாகக் கொண்ட function என்பதே காரணம். Code, ஒவ்வொரு 30 seconds-க்கும் முன்னேறும் counter-லிருந்து உருவாகிறது. எனவே server மற்றும் உங்கள் phone இரண்டும் எந்த time step தற்போது உள்ளது என்பதில் ஒத்துப்போக வேண்டும். பெரும்பாலான verifiers, தற்போதைய step-ன் இருபுறமும் தலா ஒரு step-ஐ ஏற்றுக்கொள்கின்றன. இதனால் ஒவ்வொரு திசையிலும் சுமார் அரை minute அளவுக்கு slack கிடைக்கிறது. அந்த server-ல் timedatectl-ஐச் சரிபார்க்கவும். System clock synchronized, no-ஐக் காட்டினால் sync-ஐச் சரிசெய்யவும். Shared secret-ல் எந்த மாற்றமும் செய்யாமல் codes மீண்டும் பொருந்தும்.

Docker container-க்குள் time-ஐ அமைக்க முடியுமா?

முடியாது; அதற்குத் தேவையும் இல்லை. Linux time namespaces monotonic மற்றும் boot-time clocks-ஐ மட்டும் virtualise செய்வதால், container host-ன் CLOCK_REALTIME-ஐப் பகிர்ந்து கொள்கிறது. Privilege இல்லாத container-க்கு date: cannot set date: Operation not permitted கிடைக்கும். CAP_SYS_TIME-ஐச் சேர்த்தால், container-க்கென தனி clock கிடைக்காது; அதற்கு பதிலாக host-ன் clock-ஐ மாற்ற முடியும். Host-ன் time-ஐ sync செய்யவும். Container-க்குள் வேறுபட்ட local time தேவைப்பட்டால், அது time zone setting ஆகும். எனவே container environment-ல் TZ-ஐ அமைக்கவும்.

Server UTC-ஐப் பயன்படுத்த வேண்டுமா அல்லது local time-ஐப் பயன்படுத்த வேண்டுமா?

UTC-ஐப் பயன்படுத்தவும். ஒருவர் output-ஐப் படிக்கும் இடத்தில் மட்டும் local time-ஐப் பயன்படுத்தவும். Daylight saving காரணமாக UTC ஒருபோதும் மாறாது. எனவே daily job ஆண்டு முழுவதும் தினமும் ஒருமுறை இயங்கும். வெவ்வேறு servers-ன் timestamps-ஐ எந்த conversion-மும் இல்லாமல் நேரடியாக ஒப்பிடலாம். sudo timedatectl set-timezone UTC மூலம் அதை அமைக்கவும். Local reading தேவைப்படுபவர், ஒரு command-க்கு மட்டும் prefix சேர்க்கலாம். உதாரணமாக TZ=America/New_York date-ஐப் பயன்படுத்தலாம். இது system clock-ல் எந்த மாற்றமும் செய்யாது.