VPS-এর ঘড়ি ভুল সময় দেখালে কীভাবে ঠিক করবেন

VPS-এর ঘড়ি কেন ধীরে ধীরে ভুল সময় দেখায়

কোনো VPS-এর ঘড়ি ধীরে ধীরে ভুল সময় দেখায়, কারণ সেটিকে সংশোধন করার জন্য কোনো ব্যবস্থা চলছে না। Kernel এমন একটি hardware counter থেকে সময় গণনা করে, যা সামান্য দ্রুত বা ধীর গতিতে চলে। কোনো time sync client না চললে এই সামান্য ত্রুটি প্রতি ঘণ্টায় বাড়তে থাকে। Virtual machine-এর ক্ষেত্রে আরও একটি কারণ থাকে: আপনার guest অন্য guest-গুলোর সঙ্গে একটি physical CPU ভাগ করে ব্যবহার করে। তাই guest যখন scheduled থাকে না, তখন সেই সময়ে এটি সময় গণনা করতে পারে না।

বর্তমান KVM guest-এ counter নিজে সাধারণত প্রকৃত সমস্যা নয়। Paravirtual kvm-clock source host-এর সংরক্ষিত একটি মান পড়ে। তাই সুস্থ guest সাধারণত তার host-এর সময়ের সঙ্গে ঘনিষ্ঠভাবে সামঞ্জস্য রাখে। দৃশ্যমানভাবে ভুল সময় দেখানো clock সাধারণত আরও সাধারণ কোনো কারণে ভুল থাকে। কোনো sync daemon চলছে না, অথবা দুটি daemon একে অপরের সঙ্গে বিরোধ করছে, অথবা outbound UDP port 123 আপনার provider-এর network ছেড়ে বেরোতে পারছে না। একটি guest তার সময়ের সামঞ্জস্য host অথবা NTP (network time protocol) থেকে পায়, নিজের oscillator থেকে নয়।

ভুল clock আসলে কী কী নষ্ট করে

• TOTP (time-based one-time password) দুই-ফ্যাক্টর কোড আর মেলে না। ফলে password এবং key দুটিই সঠিক হলেও server-এ প্রবেশাধিকার বন্ধ হয়ে যায়।
• এক মিনিট আগে জারি করা certificate প্রত্যাখ্যাত হয়, এবং 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) দেখিয়ে একটি repository গ্রহণ করতে অস্বীকার করে।
• নির্ধারিত কাজ ভুল সময়ে চলে। clock হঠাৎ এগিয়ে বা পিছিয়ে গেলে একটি job দুইবার চলতে পারে, আর অন্যটি বাদ পড়তে পারে।
• দুটি server-এর log একসঙ্গে মেলানো যায় না। ফলে incident timeline অনুমানের ভিত্তিতে তৈরি করতে হয়।

সহনীয় পার্থক্য অধিকাংশ মানুষের ধারণার চেয়ে কম। নিচের সংখ্যাগুলো নথিভুক্ত default; এগুলো কোনো 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 এমন একটি counter থেকে code গণনা করে, যা প্রতি 30 সেকেন্ডে অগ্রসর হয়। অধিকাংশ verifier উভয় পাশের একটি করে step গ্রহণ করে। অর্থাৎ, উভয় দিকে আধা মিনিটের ভুলই সম্পূর্ণ অনুমোদিত সীমা। Kerberos অনেক বেশি সহনশীল। এর default skew allowance হলো 300 সেকেন্ড। Certificate মোটেও সহনশীল নয়। এটি 0 সেকেন্ডের grace period সহ নির্দিষ্ট সময়ের সঙ্গে যাচাই করা হয়। তাই clock এক সেকেন্ড পিছিয়ে থাকলেও সম্পূর্ণ বৈধ একটি certificate প্রত্যাখ্যাত হয়।

তিনটি ঘড়ি, এবং কোনটি গুরুত্বপূর্ণ

সিস্টেম ঘড়ি-ই গুরুত্বপূর্ণ। এটি কার্নেলের CLOCK_REALTIME: 1 January 1970 UTC থেকে অতিবাহিত সেকেন্ডের সংখ্যা, যা মেমরিতে রাখা হয় এবং সময় সংবলিত সবকিছু এই মান পড়ে। Log line, certificate check, TOTP code এবং file modification time—সবই এই ঘড়ি থেকে আসে। কেউ যখন বলে সার্ভারের সময় ভুল, তখন তারা এই ঘড়িটির কথাই বোঝায়।

হার্ডওয়্যার ঘড়ি, যাকে RTC (real time clock) নামেও বলা হয়, একটি আলাদা counter, যা মেশিন বন্ধ থাকলেও চলতে থাকে। Physical machine-এ এটি battery-backed chip। Guest-এর ভিতরে hypervisor এটি emulate করে, তাই এটি মূলত host-এর একটি artefact। Linux boot-এর সময় starting value হিসেবে এটি একবার পড়ে, তারপর নিজের count বজায় রাখে। timedatectl এটি RTC time line-এ দেখায়। VPS-এ ওই line দেখে debugging করবেন না, কারণ এটি আপনার system clock-এর sync state নয়, বরং host-এর সময়-সংক্রান্ত ধারণা জানায়। Container-এ সাধারণত কোনো /dev/rtc থাকে না, তাই hwclock --show hwclock: Cannot access the Hardware Clock via any known method. দিয়ে ব্যর্থ হয়

Clocksource হলো ওই read-গুলোর মধ্যবর্তী সময়ে kernel যে source ব্যবহার করে count করে। আপনার kernel কোনটি বেছে নিয়েছে তা দেখুন:

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

KVM-এ সাধারণত kvm-clock দেখা যায়। এটি host দ্বারা বজায় রাখা একটি মান পড়ে। তাই কোনো NTP client না থাকলেও KVM guest কিছু সময় মোটামুটি সঠিক সময় বজায় রাখে। tsc হলো CPU-এর নিজস্ব counter। Xen guest-এ xen এবং Hyper-V guest-এ hyperv source দেখা যায়। পরিমাপ করে পরিবর্তনের কারণ না থাকলে এই setting পরিবর্তন করবেন না, কারণ ওই hardware-এ kernel ইতিমধ্যে নিজের বিশ্বস্ত সেরা source বেছে নেয়।

কিছু host guest-কে PTP (precision time protocol) device-ও দেয়। এর মাধ্যমে chrony network ব্যবহার না করে সরাসরি host clock পড়তে পারে। এটি পরীক্ষা করে দেখা উপযোগী, তবে shared VPS-এ এটি প্রায়ই পাওয়া যায় না:

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

modprobe ব্যর্থ হলে বা কোনো device দেখা না গেলে আপনার host এটি দেয় না, এবং network NTP-ই আপনার সমাধান। clock_name যদি KVM virtual clock-এর নাম দেখায়, তাহলে chrony তার config-এ একটি refclock PHC /dev/ptp0 poll 2 line ব্যবহার করতে পারে।

নিজের মেশিনে সময়ের অবস্থা দেখুন

একটি command দিয়ে শুরু করুন। এক screen-এ এটি জানায়, “এই clock-কে সঠিক রাখার জন্য কি কিছু কাজ করছে?”

timedatectl

মনে রাখা কোনো সংখ্যার ওপর নির্ভর না করে এই line-গুলো পড়ুন:

• Local time এবং Universal time একই মুহূর্তকে আপনার zone এবং UTC-তে দেখায়। দুটিতে একই সময় দেখালে machine ইতিমধ্যে UTC ব্যবহার করছে।
• RTC time উপরে বর্ণিত hardware clock। VPS-এ এটি উপেক্ষা করুন।
• Time zone local time format করার জন্য system কী ব্যবহার করে তা দেখায়।
• System clock synchronized kernel-এর নিজস্ব flag। Time daemon তার source-গুলোর ওপর আস্থা রাখলে এটি set করে। তাই no মানে boot-এর পর থেকে কোনো কিছু এই clock-কে synchronize করেনি।
• NTP service বিশেষভাবে systemd-timesyncd-এর অবস্থা জানায়। chrony চালু থাকা machine-এ n/a স্বাভাবিক, কারণ সেখানে timesyncd installed নেই। System clock synchronized: yes এবং NTP service: n/a একসঙ্গে থাকলে chrony কাজটি করছে এবং kernel-ও তা মেনে নিয়েছে।

এরপর দেখুন clock কতটা পিছিয়ে বা এগিয়ে আছে। ফোনের সময় দেখে অনুমান করবেন না। chrony চালু থাকলে:

chronyc tracking
chronyc sources -v

chronyc tracking এই প্রশ্নের উত্তর দেওয়া সংখ্যাগুলো দেখায়। System time হলো NTP time থেকে বর্তমান offset, যার পরে fast বা slow শব্দটি থাকে। Last offset হলো সর্বশেষ correction-এর পরিমাণ। Frequency হলো chrony আপনার clock-এ মাপা rate error, যা chrony ইতিমধ্যে compensate করছে। Leap status-এ Normal দেখানো উচিত। সেখানে Not synchronised দেখালে এবং Reference ID-এ 00000000 () থাকলে chrony এখনো কোনো source নির্ধারণ করেনি।

chronyc sources -v list-এর ওপরে একটি legend দেখায়, তাই symbol-গুলো মনে রাখার প্রয়োজন হয় না। সবচেয়ে গুরুত্বপূর্ণ অর্থ দুটি column-এ থাকে। প্রতিটি line-এর শুরুতে থাকা state character দিয়ে chrony ওই source-কে মূল্যায়ন করে। * চিহ্নটি বর্তমানে ব্যবহৃত source নির্দেশ করে, আর প্রতিটি line-এ ? থাকলে কোনো source সাড়া দিচ্ছে না। Reach হলো সর্বশেষ আটটি poll-এর reply history, যা octal-এ দেখানো হয়: 377 মানে আটটির সবগুলোর উত্তর এসেছে, আর 0 মানে একটিরও উত্তর আসেনি।

যদি systemd-timesyncd দায়িত্বে থাকে:

timedatectl timesync-status
timedatectl show-timesync --all

timesync-status কোন server-এর সঙ্গে যোগাযোগ করছে, poll interval এবং একটি Offset value দেখায়। command status দেখানোর বদলে service সম্পর্কে error দিলে এই machine-এ timesyncd দায়িত্বে থাকা daemon নয়। এটিই আপনার প্রশ্নের উত্তর।

অতিরিক্ত tool ছাড়া বাইরের বিশ্বের সঙ্গে মোটামুটি তুলনা করতে একটি public HTTP Date header-এর সঙ্গে আপনার clock মিলিয়ে দেখুন। এটি GMT-তে এবং এক second resolution-এ দেওয়া হয়:

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

এখানে এক বা দুই second পার্থক্য স্বাভাবিক এবং এর কোনো তাৎপর্য নেই। এক minute পার্থক্য থাকলে সেটি আপনার configuration-এর সমস্যা।

VPS-এ chrony বা systemd-timesyncd

Ubuntu এবং Debian ডিফল্টভাবে systemd-timesyncd সরবরাহ করে। এটি একটি SNTP (simple network time protocol) client। এটি একবারে একটি server-কে query করে এবং clock-কে তার সময়ের দিকে সামান্য সমন্বয় করে। যে machine সব সময় online থাকে এবং শুরুতেই মোটামুটি সঠিক সময় দেখায়, তার জন্য এটি যথেষ্ট। এটি চালানোর খরচও প্রায় নেই।

chrony একটি পূর্ণাঙ্গ NTP implementation। Virtual machine-এ এটি ভালো default, কারণ এর নিজের output-এই এর সুবিধাগুলো দেখা যায়। এটি একসঙ্গে একাধিক source poll করে এবং যেগুলো পরস্পরের সঙ্গে মেলে না, সেগুলো বাদ দেয়। এটি আপনার clock-এর rate error পরিমাপ করে drift file-এ লেখে। তাই প্রতিটি sample অনুসরণ না করে clock-এর নিজস্ব প্রবণতা সংশোধন করে। Physical machine-এর তুলনায় VM-এর যে দুটি বিশেষ আচরণ আছে, সেগুলো থেকেও এটি দ্রুত recover করতে পারে: host VM-কে pause করতে পারে, এবং চলমান অবস্থায় VM-কে অন্য host-এ সরিয়ে নিতে পারে। 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—উভয় package-ই time-daemon সরবরাহ করে। তাই chrony install করার সময় apt timesyncd সরিয়ে দেয়। এটি সঠিক এবং প্রত্যাশিত আচরণ। কখনও দুটিকে একসঙ্গে চালাবেন না। একই clock সেট করতে দুইটি daemon পরস্পরের সঙ্গে দ্বন্দ্বে জড়াবে। এই অবস্থায় কোনো daemon-এর reported offset-ই নির্ভরযোগ্য নয়। Rocky এবং AlmaLinux-এ sudo dnf install -y chrony দিয়ে install করুন। সেখানে unit-এর নাম chronyd, chrony নয়।

Debian এবং Ubuntu-তে configuration file হলো /etc/chrony/chrony.conf। Rocky এবং Alma-তে এটি /etc/chrony.conf। Distribution-এর default VPS-এর জন্য ইতিমধ্যে উপযুক্ত। তাই নির্দিষ্ট কারণ না থাকলে এটি পরিবর্তন করবেন না। দুটি directive বোঝা গুরুত্বপূর্ণ:

• pool এবং server line-এ time source-এর নাম থাকে। iburst যোগ করলে startup-এর সময় chrony দ্রুত burst পাঠায়। ফলে প্রথম sync কয়েক মিনিটের বদলে কয়েক সেকেন্ডে হয়।
• chrony কখন clock-এ সরাসরি jump করবে, আর কখন ধীরে ধীরে সমন্বয় করবে, তা makestep নির্ধারণ করে। আপনার configuration-এ কী আছে, তা grep -n makestep /etc/chrony/chrony.conf দিয়ে দেখুন। Debian এবং Ubuntu-এর default, makestep 1 3, এর অর্থ হলো: chronyd start হওয়ার পর প্রথম তিনটি update-এর সময় clock এক second-এর বেশি ভুল হলে সরাসরি step করা হবে। এরপর কেবল slewing-এর মাধ্যমে সংশোধন করা হবে।

Network path-এ tampering থেকে time traffic authenticated রাখতে চাইলে chrony 4 এবং পরবর্তী version NTS (network time security) support করে। প্রথমে chronyd -v দিয়ে version নিশ্চিত করুন। মনে রাখবেন, NTS-এর জন্য UDP 123-এর পাশাপাশি outbound TCP port 4460-ও open থাকতে হবে:

server time.cloudflare.com iburst nts

এটিকে নির্ভরযোগ্য ধরে নেওয়ার আগে restart করে যাচাই করুন। Configuration parse করতে ব্যর্থ হলে কোনো time daemon চালু থাকবে না। Clock নিজে এই ব্যর্থতার কথা জানাবে না।

sudo systemctl restart chrony
chronyc sources -v
chronyc tracking

কয়েক মিনিট ভুল থাকা ঘড়ি কেন দীর্ঘ সময় ভুলই থাকে

একটি time daemon-এর offset ঠিক করার দুটি পদ্ধতি আছে। Slewing ঘড়ির গতি বাড়ায় অথবা কমায়, যতক্ষণ না ত্রুটি দূর হয়। এতে সময় সামনের দিকেই এগোয় এবং কোনো timestamp পুনরাবৃত্তি বা বাদ পড়ে না। Stepping সরাসরি সঠিক মানে চলে যায়। এটি দ্রুত, তবে ঘড়িকে পিছিয়েও দিতে পারে। Wall clock থেকে elapsed time মাপে এমন যেকোনো কিছুর জন্য পিছিয়ে যাওয়া ঝুঁকিপূর্ণ। তাই উভয় daemon সাধারণত slewing পছন্দ করে।

এই পছন্দের কারণেই অনেক বেশি ভুল থাকা ঘড়ি দীর্ঘ সময় ভুল থাকতে পারে। chrony কেবল makestep যে window অনুমোদন করে, তার মধ্যে stepping করে। ডিফল্টভাবে এটি daemon start হওয়ার পরের প্রথম কয়েকটি update-এর সময় প্রযোজ্য। এক সপ্তাহ ধরে চালু থাকা কোনো chronyd পরে যদি চল্লিশ সেকেন্ডের error শনাক্ত করে, তবে সেটি slewing ব্যবহার করবে। চল্লিশ সেকেন্ড slew করতে আপনার অপেক্ষার ইচ্ছার চেয়ে অনেক বেশি সময় লাগবে। তাই একটি শান্ত সময় বেছে নিয়ে একবার ইচ্ছাকৃতভাবে এটি force করুন:

sudo chronyc makestep
chronyc tracking

chronyc tracking এখন শূন্যের কাছাকাছি একটি System time offset দেখাবে। Last offset এইমাত্র সংশোধন করা মানের পরিমাণ দেখাবে। ব্যস্ত database host-এ এটি চালানোর আগে ভাবুন, কারণ পিছনের দিকে clock jump করলে এমন software বিভ্রান্ত হতে পারে, যা ধরে নেয় সময় কেবল সামনের দিকেই এগোয়। একই fix-এর তুলনামূলকভাবে নিরাপদ সংস্করণ হলো daemon restart করা। কারণ start হওয়ার সময় makestep window আবার খোলে।

কনটেইনার host-এর clock শেয়ার করে

কনটেইনারের নিজস্ব wall clock নেই, তাই এর ভেতরে sync করার মতো কিছু নেই। Linux time namespace শুধু monotonic clock এবং boot-time clock virtualise করে। CLOCK_REALTIME virtualise করা হয় না। এর অর্থ, কনটেইনার যে host-এ চলছে সেটির মতো একই system clock পড়ে। host-এর clock ঠিক করলে ওই host-এর প্রতিটি কনটেইনার একই সময়ে ঠিক হয়ে যায়।

এর কয়েকটি ফল আছে। Image-এ chrony বা ntpd install করবেন না, কারণ সর্বোচ্চ ক্ষেত্রে সেটি কোনো কাজই করবে না। Unprivileged কনটেইনারের ভেতরে date সেট করলে date: cannot set date: Operation not permitted error হয়, কারণ ওই call-এর জন্য kernel-এর CAP_SYS_TIME প্রয়োজন। CAP_SYS_TIME grant করলেও কনটেইনারের private clock তৈরি হয় না। এর ফলে কনটেইনার host-এর clock পরিবর্তন করতে পারে, তাই একই host-এর অন্য সব কনটেইনারের clock-ও পরিবর্তিত হয়।

কনটেইনারের ভেতরে আলাদা time zone থাকা clock-এর সমস্যা নয়। নিজস্ব /etc/localtime থাকা image অন্য zone অনুযায়ী একই instant format করে দেখায়। তাই date ভুল মনে হতে পারে, যদিও clock সঠিক আছে। কনটেইনারের environment-এ TZ=UTC সেট করলে এই বিভ্রান্তি দূর হয়। আপনি যে runtime বেছে নিয়েছেন, তা এখানে কিছু পরিবর্তন করে না। rootless Podman এবং Docker-এর তুলনা-এ runtime-এর পরিবর্তনগুলো ব্যাখ্যা করা হয়েছে।

সার্ভারে UTC এবং ব্যবহারকারীদের জন্য স্থানীয় সময়

মেশিনটি UTC-তে সেট করুন এবং সেভাবেই রাখুন।

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

UTC-তে daylight saving নেই। এটিই মূল কারণ। daylight saving অনুসরণ করে এমন কোনো time zone-এ 02:30-এ চলা দৈনিক job ঘড়ি পিছিয়ে দেওয়ার দিনে দুবার চলে, আর ঘড়ি এগিয়ে দেওয়ার দিনে একবারও চলে না। তিন ঘণ্টার কম সময়ের পরিবর্তনের জন্য বিশেষ আচরণ man 8 cron-এ নথিভুক্ত আছে: ঘড়ি এগিয়ে দেওয়ার কারণে বাদ পড়া job পরিবর্তনের কিছুক্ষণ পর চালানো হয়, আর ঘড়ি পিছিয়ে দেওয়ার কারণে পুনরাবৃত্ত এক ঘণ্টার মধ্যে পড়া job দ্বিতীয়বার চালানো হয় না। এই আচরণ যুক্তিসংগত। তবু 03:00-এ বসে এর প্রভাব হিসাব করার প্রয়োজন থাকা উচিত নয়। UTC ব্যবহার করলে job বছরের প্রতিটি দিনে একবার করে চলে। কোনো job অস্বাভাবিক সময়ে চলার বদলে সম্পূর্ণ অনুপস্থিত থাকলে cron job নীরবে কেন কখনও চলে না তার কারণগুলো বেশি সম্ভাব্য ব্যাখ্যা।

লগ পড়ার ক্ষেত্রেও একই যুক্তি প্রযোজ্য। journalctl system time zone অনুযায়ী timestamp format করে, আর journalctl --utc UTC বাধ্যতামূলক করে। দুটি time zone-এ থাকা দুটি server প্রতিটি incident-কে সময় রূপান্তরের কাজে পরিণত করে। চাপের মধ্যে করা এই রূপান্তর থেকেই timeline প্রায়ই ভুল পড়া হয়। সিস্টেমগুলো UTC-তে রাখুন, timestamp UTC-তে সংরক্ষণ করুন, এবং কোনো মানুষ যখন তা পড়বে তখন একবার রূপান্তর করুন। কেউ একটি command-এর জন্য স্থানীয় সময় দেখতে চাইলে মেশিনের time zone পরিবর্তন না করেই তা করতে পারে:

TZ=Europe/Berlin date

timedatectl output-এর আরও একটি line এই section-এর অন্তর্ভুক্ত। RTC in local TZ-এর মান no হওয়া উচিত। Laptop-এ Windows-এর সঙ্গে dual-boot করার জন্য এটিকে yes সেট করা একটি workaround। কিন্তু server-এ এটি শুধু এমন একটি offset যোগ করে, যা পরে কারও ভুলের কারণ হতে পারে। এটি সেট করা থাকলে timedatectl একটি warning দেখায় যে system-টি RTC time স্থানীয় time zone অনুযায়ী পড়ার জন্য configured।

লক্ষণ অনুযায়ী সমস্যা সমাধান

একটি সার্ভারে আপনার two-factor code প্রত্যাখ্যাত হচ্ছে। অন্য কিছু পরীক্ষা করার আগে ঘড়ি পরীক্ষা করুন। Code-টি এমন একটি counter থেকে আসে যা প্রতি 30 সেকেন্ডে এগোয়। তাই কোনো সার্ভারের সময় 90 সেকেন্ড পিছিয়ে থাকলে সেটি এমন একটি ধাপের code গণনা করে, যেটি আপনার phone ইতিমধ্যে অতিক্রম করেছে। timedatectl দেখাবে System clock synchronized: no, অথবা chronyc tracking বড় System time offset দেখাবে। এটি সরাসরি প্রত্যাখ্যাত cryptographic 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-এ থাকা তারিখের চেয়ে পিছিয়ে আছে। ওই duration সরাসরি কতটা পিছিয়ে আছে তা দেখায়। Clock ঠিক করুন। এটি এড়াতে apt-এর date check নিষ্ক্রিয় করবেন না। কারণ এই check-ই আপনাকে stale package index সরবরাহ করা ঠেকায়।

প্রতিটি source line-এ unreachable state দেখায় এবং Reach-এর মান 0। কোনো কিছুই response দিচ্ছে না। তাই configuration-এর বদলে egress পরীক্ষা করুন। NTP outbound UDP port 123 ব্যবহার করে, এবং কিছু network এটি filter বা redirect করে। sudo chronyc ntpdata প্রতিটি source-এর counter দেখায়, যার মধ্যে Total TX এবং Total RX রয়েছে। RX শূন্য থাকা অবস্থায় TX count বাড়তে থাকলে বোঝায় আপনার packet বাইরে যাচ্ছে, কিন্তু কোনো packet ফিরে আসছে না। এটি আপনার এবং source-এর মাঝের firewall-এর দিকে নির্দেশ করে।

Clock সঠিক ছিল, পরে হঠাৎ পরিবর্তিত হয়েছে। Host-এর event এমনটি ঘটাতে পারে। Restored snapshot, paused guest বা অন্য host-এ live migration হলে guest-এর সময়ের ধারণা প্রকৃত সময়ের চেয়ে পিছিয়ে যেতে পারে। chrony পরবর্তী poll-এ এটি শনাক্ত করে এবং সংশোধন করে। systemd-timesyncd প্রথমে দীর্ঘ poll interval শেষ হওয়া পর্যন্ত অপেক্ষা করতে পারে। systemctl is-enabled chrony দিয়ে daemon boot-এর সময় start হয় কি না নিশ্চিত করুন। হাতে start করা daemon পরবর্তী reboot-এর পরে আর চলবে না।

Offset কম, কিন্তু কখনও স্থির হয় না। CPU steal পরীক্ষা করুন। Timer interrupt হওয়ার সময় কোনো guest scheduled না হলে তার sample দেরিতে নেওয়া হয়। ফলে offset ধীরে ধীরে স্থির না হয়ে পরিবর্তিত হতে থাকে। top CPU line-এ এটিকে st figure হিসেবে দেখায়। shared host-এ CPU steal time পড়ার নির্দেশিকায় এই সংখ্যার অর্থ এবং এটি কমানোর করণীয় ব্যাখ্যা করা হয়েছে।

আপনি সদ্য issue করা একটি certificate not yet valid হিসেবে প্রত্যাখ্যাত হচ্ছে। curl SSL certificate problem: certificate is not yet valid দেখায়, এবং browser-ও একই ধরনের message দেখায়। Certificate-এ সমস্যা নেই; যে clock এটি পরীক্ষা করছে সেটি পিছিয়ে আছে। ভুলটি client অথবা server—যেকোনো একটির হতে পারে। তাই উভয়টি পরীক্ষা করুন। Certificate issue করা server-এর clock ভুল হলে, certbot এবং nginx certificate নির্দেশিকায় একই setup-এর renewal অংশ ব্যাখ্যা করা হয়েছে।

আপনি যে checks ইতিমধ্যে চালান, তার সঙ্গে এটিও যোগ করুন

Time sync boot-time setting হিসেবে নির্ধারিত হয়, কিন্তু কয়েক মাস পরে নীরবে ব্যর্থ হতে পারে। এ ধরনের সমস্যা routine ধরতে পারে, memory পারে না। timedatectl এবং chronyc tracking একসঙ্গে পড়তে দুই সেকেন্ড লাগে। এগুলো নতুন VPS-এ প্রথম দশ মিনিটের কাজের অংশ হিসেবে চালান। এরপর নিয়মিত Linux server maintenance checklist অনুসরণ করার সময় আবার চালান। Offset বেড়ে গেলে check নিজে চালিয়ে আপনাকে সতর্ক করাতে চাইলে systemd service এবং timer লেখা একটি ছোট unit-এর জন্য প্রয়োজনীয় pattern দেখায়। এ ধরনের check daemon নয়, একটি ছোট script। তাই default-এর পরিবর্তে এটি Type=oneshot চায়। systemd service type-গুলোর সংক্ষিপ্ত ব্যাখ্যা দেখায়, ভুল type ব্যবহার করলে কেন এমন একটি unit পাওয়া যায়, যা কখনো অর্জন না করা success report করে।

FAQ

VPS-এর clock sync অবস্থায় আছে কি না কীভাবে পরীক্ষা করব?

timedatectl চালিয়ে System clock synchronized লাইনটি পড়ুন। এটি kernel-এর নিজস্ব flag, যা clock নিয়ন্ত্রণকারী daemon সেট করে। তাই chrony-চালিত মেশিনে yes-এর সঙ্গে NTP service: n/a দেখা স্বাভাবিক এবং সঠিক। ত্রুটির পরিমাণ জানতে chronyc tracking চালিয়ে System time পড়ুন। systemd-timesyncd দায়িত্বে থাকলে timedatectl timesync-status চালিয়ে Offset পড়ুন। মেশিনের বাইরের কোনো উৎসের সঙ্গে পরীক্ষা করতে HTTPS site থেকে পাওয়া Date header-এর সঙ্গে date -u তুলনা করুন।

VPS-এ chrony নাকি systemd-timesyncd ব্যবহার করা উচিত?

গুরুত্বপূর্ণ যেকোনো মেশিনে chrony ব্যবহার করুন। systemd-timesyncd হলো একটি SNTP client, যা একটি server অনুসরণ করে। সব সময় online থাকে এবং শুরুতেই সময় মোটামুটি সঠিক থাকে—এমন মেশিনে এটি যথেষ্ট। chrony একাধিক source থেকে poll করে, যেগুলোর সময় মেলে না সেগুলো বাদ দেয়, clock-এর rate error শিখে নেয় এবং host pause বা live migration-এর পরে দ্রুত সময় ঠিক করে। Debian বা Ubuntu-তে chrony install করলে systemd-timesyncd স্বয়ংক্রিয়ভাবে সরিয়ে দেওয়া হয়, কারণ উভয় package-ই time-daemon প্রদান করে। একই সময়ে কখনও দুটি time daemon চালাবেন না।

একটি server-এ আমার TOTP code ব্যর্থ হয়, কিন্তু অন্য সব জায়গায় কাজ করে কেন?

কারণ TOTP code বর্তমান সময়ের একটি function। Code একটি counter থেকে আসে, যা প্রতি 30 সেকেন্ডে এগোয়। তাই server এবং আপনার phone-কে একই time step-এ একমত হতে হয়। বেশিরভাগ verifier দুই পাশের একটি করে step গ্রহণ করে। ফলে উভয় দিকে মোটামুটি আধা মিনিটের allowance থাকে। ওই server-এ timedatectl পরীক্ষা করুন। System clock synchronized যদি no পড়ে, sync ঠিক করুন। Shared secret পরিবর্তন না করেই code আবার মিলে যাবে।

Docker container-এর ভিতরে সময় নির্ধারণ করা যাবে কি?

না, এবং এর প্রয়োজনও নেই। একটি container host-এর CLOCK_REALTIME share করে, কারণ Linux time namespace শুধু monotonic এবং boot-time clock virtualise করে। একটি unprivileged container পায় date: cannot set date: Operation not permitted। CAP_SYS_TIME যোগ করলে container-এর নিজস্ব clock দেওয়ার বদলে host-এর clock পরিবর্তনের অনুমতি দেওয়া হয়। তাই host-এর সময় sync করুন। Container-এর ভিতরে আলাদা local time আসলে time zone setting। Container environment-এ TZ সেট করুন।

Server-এ UTC নাকি local time ব্যবহার করা উচিত?

UTC ব্যবহার করুন। কোনো ব্যক্তি output পড়ার সময় local time প্রয়োগ করুন। Daylight saving-এর কারণে UTC কখনও পরিবর্তিত হয় না। তাই সারা বছর daily job দিনে একবার চলে এবং conversion ছাড়াই বিভিন্ন server-এর timestamp মিলিয়ে দেখা যায়। sudo timedatectl set-timezone UTC দিয়ে এটি সেট করুন। কেউ local reading চাইলে একটি command-এর আগে prefix দিতে পারেন, যেমন TZ=America/New_York date। এতে system clock-এর কোনো পরিবর্তন হয় না।