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 থেকে নয়।

একটি ভুল ঘড়ি আসলে কী কী নষ্ট করে

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

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

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

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

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

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 কিছু সময় মোটামুটি সঠিক সময় ধরে রাখতে পারে। 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-এর নাম দেখায়, তাহলে configuration-এ refclock PHC /dev/ptp0 poll 2 line ব্যবহার করে chrony এটি কাজে লাগাতে পারে।

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

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

timedatectl

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

• Local time এবং Universal time আপনার zone এবং UTC-তে একই মুহূর্ত দেখায়। দুটির মান অভিন্ন হলে মেশিনটি ইতিমধ্যে 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 চালানো মেশিনে 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 আপনার clock-এর rate error, যা chrony পরিমাপ করেছে এবং ইতিমধ্যে সমন্বয় করছে। Leap status-এর মান Normal হওয়া উচিত। এটি Not synchronised হলে এবং Reference ID-এর মান 00000000 () হলে chrony এখনো কোনো source নির্ধারণ করতে পারেনি।

chronyc sources -v তালিকার উপরে একটি 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 দিলে এই মেশিনে timesyncd দায়িত্বে থাকা daemon নয়। এটিই আপনার প্রশ্নের উত্তর।

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

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

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

VPS-এ chrony নাকি systemd-timesyncd

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

chrony একটি পূর্ণাঙ্গ NTP implementation। Virtual machine-এর জন্য এটি ভালো default। এর নিজস্ব output-এই এর কারণগুলো দেখা যায়। এটি একসঙ্গে একাধিক source poll করে এবং যেগুলোর সময়ের মধ্যে অমিল থাকে সেগুলো বাদ দেয়। এটি আপনার clock-এর rate error মেপে drift file-এ লিখে রাখে। ফলে প্রতিটি sample অনুসরণ না করে clock-এর ধারাবাহিক প্রবণতা সংশোধন করে। Physical machine-এর তুলনায় VM-এ যে দুটি পরিস্থিতি ঘটে, সেগুলো থেকেও এটি দ্রুত পুনরুদ্ধার করতে পারে: 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 নির্ধারণ করে। আপনার সেটিং দেখতে grep -n makestep /etc/chrony/chrony.conf চালান। Debian এবং Ubuntu-র default, makestep 1 3, এর অর্থ হলো: chronyd start হওয়ার পর প্রথম তিনটি update-এর সময় clock এক second-এর বেশি ভুল হলে সেটিকে সরাসরি সংশোধন করবে। এরপর শুধু slewing করে সংশোধন করবে।

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

server time.cloudflare.com iburst nts

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

sudo systemctl restart chrony
chronyc sources -v
chronyc tracking

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

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

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

sudo chronyc makestep
chronyc tracking

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

Container host-এর clock শেয়ার করে

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

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

Container-এর ভেতরে ভিন্ন time zone ব্যবহার করা clock-এর সমস্যা নয়। নিজস্ব /etc/localtime থাকা image অন্য একটি zone অনুযায়ী একই মুহূর্ত format করে দেখায়। তাই date ভুল মনে হতে পারে, যদিও clock সঠিক থাকে। Container 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 পরিবর্তনের পরপরই চালানো হয়, আর ঘড়ি পিছিয়ে দেওয়ার কারণে পুনরাবৃত্ত hour-এর মধ্যে পড়া job দ্বিতীয়বার চালানো হয় না। এই আচরণ যুক্তিসঙ্গত হলেও, 03:00-এ বসে এর প্রভাব বিশ্লেষণ করার প্রয়োজন আপনার হওয়া উচিত নয়। UTC ব্যবহার করলে job বছরের প্রতিদিন একবার করে চলে। আপনার কোনো job অস্বাভাবিক সময়ে চালানোর পরিবর্তে পুরোপুরি অনুপস্থিত থাকলে, cron job নীরবে কেন কখনো চলে না তার কারণ-ই বেশি সম্ভাব্য ব্যাখ্যা।

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

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 প্রতি 30 সেকেন্ডে অগ্রসর হওয়া একটি counter থেকে তৈরি হয়। তাই কোনো সার্ভার 90 সেকেন্ড পিছিয়ে থাকলে সেটি এমন একটি ধাপের code তৈরি করে, যেটি আপনার ফোন ইতিমধ্যে অতিক্রম করেছে। timedatectl দেখাবে System clock synchronized: no, অথবা chronyc tracking বড় System time offset দেখাবে। key সরাসরি প্রত্যাখ্যাত হওয়ার ঘটনা আলাদা। সে ক্ষেত্রে নিজস্ব message প্রদর্শিত হয় এবং এর ব্যাখ্যা publickey authentication ব্যর্থতার নির্দেশিকা-তে রয়েছে।

apt update বলছে যে একটি Release file এখনও বৈধ নয়। সম্পূর্ণ message-এ repository এবং এটি কতক্ষণ invalid থাকবে তা উল্লেখ থাকে, যেমন is not valid yet (invalid for another 1d 2h 3min 4s)। আপনার clock repository-এর Release file-এ থাকা তারিখের চেয়ে পিছিয়ে আছে। উল্লেখিত সময়কালটি clock কতটা পিছিয়ে আছে তার সরাসরি পরিমাপ। 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-এর ঘটনা এমনটি ঘটাতে পারে। Restored snapshot, paused guest বা অন্য host-এ live migration হলে guest-এর time বাস্তব সময়ের তুলনায় পিছিয়ে যেতে পারে। পরবর্তী poll-এ chrony এটি শনাক্ত করে এবং সংশোধন করে। systemd-timesyncd প্রথমে দীর্ঘ poll interval শেষ হওয়া পর্যন্ত অপেক্ষা করতে পারে। systemctl is-enabled chrony ব্যবহার করে নিশ্চিত করুন যে daemon boot-এর সময় start হচ্ছে। হাতে start করা daemon পরবর্তী reboot-এর পরে আর চলবে না।

offset কম, কিন্তু কখনও স্থির হয় না। CPU steal পরীক্ষা করুন। কোনো guest তার timer interrupt নির্ধারিত সময়ে 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 ভুল হলে, একই setup-এর renewal অংশের জন্য certbot এবং nginx certificate নির্দেশিকা দেখুন।

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

Time sync হলো boot-time সেটিং, যা কয়েক মাস পরে নীরবে ব্যর্থ হতে পারে। এই কারণেই routine check এমন সমস্যা ধরে ফেলে, যা স্মৃতির ওপর নির্ভর করলে বাদ পড়ে। timedatectl এবং chronyc tracking একসঙ্গে পড়তে দুই সেকেন্ড লাগে। নতুন VPS-এ প্রথম দশ মিনিটের কাজের তালিকা অনুসরণ করার সময় এগুলো চালান। এছাড়া নিয়মিত Linux server maintenance checklist অনুসরণ করার সময়ও আবার চালান। offset বেড়ে গেলে check নিজে চলুক এবং সতর্কবার্তা দিক—এমন ব্যবস্থা চাইলে একটি systemd service এবং timer লেখা নির্দিষ্ট সময়সূচিতে status report দেওয়া ছোট unit তৈরির পদ্ধতি দেখায়।

FAQ

VPS-এর ঘড়ি সঠিকভাবে সমন্বিত আছে কি না কীভাবে পরীক্ষা করব?

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

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

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

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

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

Docker container-এর ভেতরে সময় সেট করা যাবে কি?

না, এবং এর প্রয়োজনও নেই। একটি container host-এর CLOCK_REALTIME ভাগ করে ব্যবহার করে, কারণ 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 প্রতিদিন একবার চলে এবং বিভিন্ন server-এর timestamp কোনো conversion ছাড়াই পরস্পরের সঙ্গে মেলে। sudo timedatectl set-timezone UTC দিয়ে এটি সেট করুন। কেউ local reading চাইলে একটি command-এর আগে prefix যোগ করতে পারেন, যেমন TZ=America/New_York date। এতে system clock-এর কোনো পরিবর্তন হয় না।