VPS کی گھڑی کا وقت کیوں بدلتا ہے اور اسے کیسے درست کریں

آپ کے VPS کی گھڑی میں وقت کا انحراف کیوں ہوتا ہے

VPS کی گھڑی میں وقت کا انحراف اس لیے ہوتا ہے کہ اسے درست کرنے والا کوئی نظام فعال نہیں ہوتا۔ Kernel وقت کا حساب ایک hardware counter سے کرتا ہے، جو معمولی طور پر تیز یا سست چل سکتا ہے۔ اگر time sync client نہ چل رہا ہو تو یہ معمولی غلطی ہر گھنٹے کے ساتھ بڑھتی جاتی ہے۔ Virtual machine کے اندر ایک دوسری وجہ بھی ہوتی ہے: آپ کا guest physical CPU دوسرے guests کے ساتھ share کرتا ہے، اس لیے جن لمحات میں اسے schedule نہیں کیا جاتا، ان لمحات میں وہ وقت کا حساب نہیں رکھ سکتا۔

موجودہ KVM guest میں counter خود شاذونادر ہی اصل مسئلہ ہوتا ہے۔ Paravirtual kvm-clock source وہ قدر پڑھتا ہے جسے host برقرار رکھتا ہے، اس لیے صحت مند guest اپنے host کے وقت کے ساتھ قریب سے ہم آہنگ رہتا ہے۔ جو گھڑیاں واضح طور پر غلط وقت دکھاتی ہیں، ان کی وجہ عموماً زیادہ سادہ ہوتی ہے۔ کوئی sync daemon چل نہیں رہا ہوتا، یا دو daemon ایک دوسرے سے متصادم ہوتے ہیں، یا outbound UDP port 123 آپ کے provider کے network سے باہر نہیں نکلتا۔ Guest اپنے وقت کی درستی host یا NTP (network time protocol) سے حاصل کرتا ہے، اپنے oscillator سے نہیں۔

غلط گھڑی دراصل کیا خراب کرتی ہے

• TOTP (time-based one-time password) کے two-factor codes آپس میں مطابقت نہیں رکھتے، اس لیے آپ ایسے سرور سے باہر ہو جاتے ہیں جس کا password اور key دونوں درست ہیں۔
• ایک منٹ پہلے جاری کیا گیا 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 قبول نہیں کرتا۔
• Scheduled کام غلط وقت پر چلتا ہے، اور گھڑی میں اچانک تبدیلی سے ایک job دو بار چل سکتی ہے جبکہ دوسری skip ہو سکتی ہے۔
• دو سرورز کے logs کو ایک دوسرے کے مطابق نہیں رکھا جا سکتا، اس لیے incident timeline اندازے سے تیار کرنی پڑتی ہے۔

یہ tolerance زیادہ تر لوگوں کی توقع سے کم ہے۔ ذیل کے اعداد documented defaults ہیں، test سے حاصل کی گئی measurements نہیں۔

[
  {
    "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 سے calculate ہوتا ہے جو ہر 30 seconds بعد آگے بڑھتا ہے، اور زیادہ تر verifiers ایک step پہلے یا بعد والا code بھی قبول کرتے ہیں۔ ہر سمت میں آدھے منٹ کی غلطی ہی پوری گنجائش ہے۔ Kerberos اس کے مقابلے میں کہیں زیادہ رعایت دیتا ہے، جس میں default skew allowance 300 seconds ہے۔ Certificate کسی رعایت کے بغیر fixed instants کے مطابق check کیا جاتا ہے، جس میں 0 seconds کا grace period ہوتا ہے؛ اس لیے ایک second پیچھے چلنے والی گھڑی ایسا certificate مسترد کر دیتی ہے جو بالکل valid ہو۔

تین گھڑیاں، اور ان میں سے کون سی اہم ہے

سسٹم کلاک وہ گھڑی ہے جو اہم ہے۔ یہ kernel کا CLOCK_REALTIME ہے: 1 January 1970 UTC سے گزرنے والے seconds کی تعداد، جو memory میں رکھی جاتی ہے اور وقت درج کرنے والی ہر چیز اسے پڑھتی ہے۔ Log lines، certificate checks، TOTP codes اور file modification times سب اسی سے حاصل ہوتے ہیں۔ جب کوئی کہتا ہے کہ server کا وقت غلط ہے، تو اس کی مراد یہی گھڑی ہوتی ہے۔

ہارڈویئر کلاک، جسے RTC (real time clock) بھی کہا جاتا ہے، ایک الگ counter ہے جو machine بند ہونے کے دوران بھی چلتا رہتا ہے۔ Physical machine میں یہ battery-backed chip ہوتی ہے۔ Guest کے اندر اسے hypervisor emulate کرتا ہے، اس لیے یہ زیادہ تر host کی فراہم کردہ قدر ہوتی ہے۔ Linux boot کے وقت ابتدائی قدر کے لیے اسے ایک بار پڑھتا ہے، پھر اپنی الگ گنتی جاری رکھتا ہے۔ timedatectl اسے RTC time line پر دکھاتا ہے۔ VPS پر debugging کے لیے اس line پر انحصار نہ کریں، کیونکہ یہ آپ کے system clock کی sync state کے بجائے host کے time estimate کے بارے میں بتاتی ہے۔ Container میں عموماً کوئی /dev/rtc موجود نہیں ہوتا، اس لیے hwclock --show، hwclock: Cannot access the Hardware Clock via any known method. کے ساتھ fail ہوتا ہے

کلاک سورس وہ ذریعہ ہے جس کے ذریعے kernel ان readings کے درمیان وقت گنتا ہے۔ اپنے kernel سے پوچھیں کہ اس نے کون سا clocksource منتخب کیا ہے:

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

KVM پر عموماً kvm-clock دکھائی دے گا۔ یہ host کے برقرار رکھے ہوئے value کو پڑھتا ہے، اسی لیے ایسا KVM guest جس میں NTP client بالکل نہ ہو، کچھ عرصے تک تقریباً درست وقت برقرار رکھتا ہے۔ tsc CPU کا اپنا counter ہے۔ Xen guests xen report کرتے ہیں، جبکہ Hyper-V guests hyperv source report کرتے ہیں۔ اس setting کو تبدیل نہ کریں، جب تک اسے تبدیل کرنے کی کوئی باقاعدہ پیمائش پر مبنی وجہ نہ ہو، کیونکہ kernel پہلے ہی اس hardware پر اپنے قابلِ اعتماد بہترین source کا انتخاب کرتا ہے۔

کچھ hosts guest کو PTP (precision time protocol) device بھی فراہم کرتے ہیں۔ اس سے chrony network کے بجائے host clock کو براہِ راست پڑھ سکتا ہے۔ اسے check کرنا مفید ہے، تاہم 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 کے ذریعے اسے استعمال کر سکتا ہے۔

اپنی مشین پر وقت کی حالت پڑھیں

ایک command سے شروع کریں۔ یہ ایک ہی screen پر جواب دیتا ہے کہ آیا کوئی چیز اس clock کو درست رکھ رہی ہے۔

timedatectl

کسی یاد رکھے ہوئے number پر بھروسا کرنے کے بجائے یہ lines پڑھیں:

• Local time اور Universal time ایک ہی instant کو آپ کے zone اور UTC میں دکھاتے ہیں۔ اگر دونوں یکساں ہوں تو مشین پہلے ہی UTC پر ہے۔
• RTC time وہ hardware clock ہے جس کا اوپر ذکر کیا گیا ہے۔ VPS پر اسے نظرانداز کریں۔
• Time zone وہ format ہے جسے system local time دکھانے کے لیے استعمال کرتا ہے۔
• System clock synchronized kernel کا اپنا flag ہے۔ time daemon اپنے sources پر اعتماد ہونے کے بعد اسے set کرتا ہے، اس لیے no کا مطلب ہے کہ boot کے بعد سے کسی چیز نے اس clock کو discipline نہیں کیا۔
• NTP service خاص طور پر systemd-timesyncd کی حالت بتاتا ہے۔ chrony چلانے والی مشین پر n/a معمول کی بات ہے، کیونکہ وہاں timesyncd installed نہیں ہوتا۔ System clock synchronized: yes کے ساتھ NTP service: n/a کا مطلب ہے کہ کام chrony کر رہا ہے اور kernel بھی اس سے متفق ہے۔

اب معلوم کریں کہ clock کتنا آگے یا پیچھے ہے۔ اسے اپنے phone سے اندازاً نہ ملائیں۔ اگر chrony چل رہا ہو:

chronyc tracking
chronyc sources -v

chronyc tracking وہ numbers دکھاتا ہے جو اس سوال کا جواب دیتے ہیں۔ System time NTP time کے مقابلے میں موجودہ offset ہے، جس کے بعد fast یا slow لفظ آتا ہے۔ Last offset حالیہ correction کی مقدار ہے۔ Frequency وہ rate error ہے جسے chrony نے آپ کی clock میں ناپا ہے اور جس کی پہلے ہی تلافی کر رہا ہے۔ Leap status کی قدر Normal ہونی چاہیے۔ اگر اس کی قدر Not synchronised ہو اور Reference ID، 00000000 () ہو تو chrony نے ابھی کسی source پر اعتماد قائم نہیں کیا۔

chronyc sources -v فہرست کے اوپر ایک legend دکھاتا ہے، اس لیے آپ کو symbols یاد رکھنے کی ضرورت نہیں۔ زیادہ تر مفہوم دو columns میں ہوتا ہے۔ ہر line کے شروع کا state character بتاتا ہے کہ chrony اس source کو کس درجہ پر رکھتا ہے؛ * اس source کو نشان زد کرتا ہے جسے وہ اس وقت استعمال کر رہا ہے، جبکہ ہر line پر ? کا مطلب ہے کہ کوئی جواب نہیں دے رہا۔ Reach آخری آٹھ polls کی 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 دے تو اس box پر timesyncd ذمہ دار daemon نہیں ہے۔ یہی آپ کے سوال کا جواب ہے۔

بغیر اضافی tools کے بیرونی دنیا کے مقابلے میں ایک تقریبی جانچ کے لیے اپنی clock کا موازنہ public HTTP Date header سے کریں۔ یہ GMT میں، ایک second کی resolution کے ساتھ فراہم ہوتا ہے:

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

یہاں ایک یا دو seconds کا فرق معمول کی بات ہے اور اس کی کوئی اہمیت نہیں۔ ایک minute کا فرق آپ کی bug ہے۔

VPS پر chrony یا systemd-timesyncd

Ubuntu اور Debian میں systemd-timesyncd پہلے سے شامل ہوتا ہے۔ یہ SNTP (simple network time protocol) client ہے۔ یہ ایک وقت میں ایک server سے وقت حاصل کرتا ہے اور clock کو اس کے مطابق معمولی طور پر درست کرتا ہے۔ جو machine مسلسل online رہتی ہو اور ابتدا میں تقریباً درست وقت رکھتی ہو، اس کے لیے یہ کافی ہے۔ اسے چلانے کے وسائل بھی تقریباً نہ ہونے کے برابر ہیں۔

chrony مکمل NTP implementation ہے اور virtual machine کے لیے بہتر default ہے۔ اس کی وجوہات اس کے اپنے output میں دیکھی جا سکتی ہیں۔ یہ بیک وقت کئی sources سے وقت حاصل کرتا ہے اور اختلاف کرنے والے sources کو خارج کر دیتا ہے۔ یہ آپ کی clock کی rate error ناپ کر اسے drift file میں لکھتا ہے۔ اس طرح یہ ہر sample کے پیچھے چلنے کے بجائے clock کے مستقل رجحان کو درست کرتا ہے۔ یہ ان دو صورتوں سے بھی تیزی سے بحال ہو جاتا ہے جو physical box کے بجائے VM میں پیش آتی ہیں: host اسے pause کر سکتا ہے، اور running حالت میں اسے مختلف 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 دونوں packages time-daemon فراہم کرتے ہیں، اس لیے apt، chrony install کرتے وقت timesyncd کو remove کر دیتا ہے۔ یہ درست اور مطلوبہ عمل ہے۔ دونوں کو کبھی ساتھ نہ چلائیں، کیونکہ ایک ہی clock set کرنے والے دو daemons آپس میں تصادم کریں گے۔ جب دونوں ایسا کر رہے ہوں تو کسی ایک کے بتائے ہوئے offset پر اعتماد نہیں کیا جا سکتا۔ Rocky اور AlmaLinux پر sudo dnf install -y chrony کے ذریعے install کریں۔ وہاں unit کا نام chronyd ہوتا ہے، chrony نہیں۔

Debian اور Ubuntu میں config file /etc/chrony/chrony.conf ہے، جبکہ Rocky اور Alma میں /etc/chrony.conf ہے۔ Distribution default پہلے ہی VPS کے لیے مناسب ہے، اس لیے اسے صرف واضح وجہ کی صورت میں تبدیل کریں۔ دو directives کو سمجھنا مفید ہے:

• pool اور server lines وقت کے sources کے نام بتاتی ہیں۔ iburst شامل کرنے سے chrony کو startup پر تیز burst بھیجنے کی ہدایت ملتی ہے۔ اس سے پہلا sync minutes کے بجائے seconds میں ہو جاتا ہے۔
• makestep یہ طے کرتا ہے کہ chrony clock کو آہستہ آہستہ درست کرنے کے بجائے کب jump کرے گا۔ اپنی setting grep -n makestep /etc/chrony/chrony.conf سے دیکھیں۔ Debian اور Ubuntu کا default، makestep 1 3، کا مطلب یہ ہے: chronyd شروع ہونے کے بعد پہلی three updates کے دوران، اگر clock میں ایک second سے زیادہ فرق ہو تو اسے step کے ذریعے درست کریں؛ اس کے بعد صرف slewing کے ذریعے correction کریں۔

اگر آپ path پر tampering کے خلاف time traffic کی authentication چاہتے ہیں تو chrony 4 اور اس کے بعد کے versions NTS (network time security) support کرتے ہیں۔ پہلے chronyd -v سے اپنا version confirm کریں۔ یہ بھی یاد رکھیں کہ NTS کے لیے UDP 123 کے علاوہ outbound TCP port 4460 بھی open ہونا چاہیے:

server time.cloudflare.com iburst nts

اس پر اعتماد کرنے سے پہلے service restart کریں اور verification کریں۔ اگر config parse نہ ہو سکے تو time daemon بالکل نہیں چلے گا، اور clock آپ کو اس failure سے آگاہ نہیں کرے گی۔

sudo systemctl restart chrony
chronyc sources -v
chronyc tracking

وہ گھڑی جو چند منٹ غلط ہو، غلط ہی کیوں رہتی ہے

وقت کا daemon offset درست کرنے کے دو طریقے استعمال کرتا ہے۔ Slewing سے گھڑی کی رفتار بڑھائی یا کم کی جاتی ہے، یہاں تک کہ فرق ختم ہو جائے۔ اس عمل میں وقت مسلسل آگے بڑھتا ہے اور کوئی timestamp دہرایا یا چھوڑا نہیں جاتا۔ Stepping میں گھڑی کو براہِ راست درست قدر پر منتقل کیا جاتا ہے۔ یہ تیز طریقہ ہے، لیکن گھڑی کو پیچھے بھی کر سکتا ہے۔ Wall clock سے گزرے ہوئے وقت کی پیمائش کرنے والے سافٹ ویئر کے لیے پیچھے جانا خطرناک ہے، اس لیے دونوں daemons عموماً slew کو ترجیح دیتے ہیں۔

اسی ترجیح کی وجہ سے بہت زیادہ غلط گھڑی کافی دیر تک غلط رہ سکتی ہے۔ chrony صرف اسی وقت step کرتا ہے جب فرق اس window کے اندر ہو جس کی اجازت makestep دیتا ہے۔ پہلے سے طے شدہ طور پر یہ window daemon کے شروع ہونے کے بعد کی ابتدائی چند updates تک محدود ہوتی ہے۔ اگر chronyd ایک ہفتے سے چل رہا ہو اور پھر اسے چالیس سیکنڈ کا فرق ملے تو وہ اسے slew کرے گا۔ چالیس سیکنڈ کو slew کرنے میں آپ کی مطلوبہ انتظار کی مدت سے کہیں زیادہ وقت لگتا ہے۔ اسے ایک بار، جان بوجھ کر، کم مصروف وقت میں فوراً درست کریں:

sudo chronyc makestep
chronyc tracking

اب chronyc tracking کو تقریباً صفر کے قریب System time offset دکھانا چاہیے، اور Last offset سے معلوم ہونا چاہیے کہ ابھی کتنا فرق درست کیا گیا۔ مصروف database host پر یہ command چلانے سے پہلے سوچیں، کیونکہ پیچھے جانے والی گھڑی ایسے سافٹ ویئر کو الجھا سکتی ہے جو یہ فرض کرتا ہے کہ وقت صرف آگے بڑھتا ہے۔ daemon کو restart کرنا اسی اصلاح کا نسبتاً محتاط طریقہ ہے، کیونکہ start کے وقت makestep window دوبارہ کھل جاتی ہے۔

کنٹینرز میزبان کی گھڑی استعمال کرتے ہیں

کنٹینر کی اپنی wall clock نہیں ہوتی، اس لیے اس کے اندر sync کرنے کے لیے کچھ موجود نہیں ہوتا۔ Linux time namespaces صرف monotonic اور boot-time clocks کو virtualise کرتے ہیں۔ CLOCK_REALTIME کو virtualise نہیں کیا جاتا، اس کا مطلب ہے کہ کنٹینر اسی system clock کو پڑھتا ہے جو اس میزبان کی ہے جس پر وہ چل رہا ہے۔ میزبان کی clock درست کریں، اور اس میزبان کے تمام کنٹینرز اسی لمحے درست ہو جائیں گے۔

اس کے چند نتائج سامنے آتے ہیں۔ image میں chrony یا ntpd install نہ کریں، کیونکہ بہترین صورت میں بھی اس کا کوئی اثر نہیں ہوگا۔ غیر privileged کنٹینر کے اندر date set کرنے سے date: cannot set date: Operation not permitted کے ساتھ failure ہوتی ہے، کیونکہ kernel اس call کے لیے CAP_SYS_TIME درکار کرتا ہے۔ CAP_SYS_TIME دینے سے کنٹینر کو private clock نہیں ملتی؛ اسے میزبان کی clock تبدیل کرنے کی صلاحیت ملتی ہے، اور اس طرح ہر دوسرے کنٹینر کی clock بھی تبدیل ہو جاتی ہے۔

کنٹینر کے اندر مختلف time zone ہونا clock کا مسئلہ نہیں ہے۔ اپنی /etc/localtime رکھنے والی image اسی instant کو دوسرے zone کے مطابق format کر کے دکھاتی ہے، اس لیے date غلط دکھائی دے سکتا ہے جبکہ clock درست ہوتی ہے۔ کنٹینر کے environment میں TZ=UTC set کریں، تو یہ الجھن دور ہو جاتی ہے۔ آپ نے جو runtime منتخب کیا ہے، وہ اس معاملے میں کچھ نہیں بدلتا، اور rootless Podman اور Docker کا موازنہ بتاتا ہے کہ وہ کیا بدلتا ہے۔

وقت کے زون: server پر UTC، لوگوں کے لیے local time

machine کو UTC پر set کریں اور اسے اسی حالت میں رہنے دیں۔

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

UTC میں daylight saving نہیں ہوتی، اور یہی بنیادی دلیل ہے۔ daylight saving رکھنے والے zone میں 02:30 پر چلنے والا روزانہ کا job گھڑی پیچھے ہونے والے دن دو بار چلتا ہے، اور گھڑی آگے ہونے والے دن بالکل نہیں چلتا۔ man 8 cron تین گھنٹے سے کم shifts کے لیے خصوصی handling بیان کرتا ہے: forward jump سے skip ہونے والے jobs تبدیلی کے فوراً بعد چلائے جاتے ہیں، جبکہ backward jump سے repeated hour کے اندر آنے والے jobs دوسری بار نہیں چلتے۔ یہ رویہ مناسب ہے، لیکن 03:00 بجے آپ کو اس کے بارے میں سوچنے کی ضرورت نہیں ہونی چاہیے۔ UTC کے تحت job سال کے ہر دن ایک بار چلتا ہے۔ اگر آپ کا کوئی job غیر معمولی وقت پر چلنے کے بجائے مکمل طور پر missing ہے تو cron job کے خاموشی سے کبھی نہ چلنے کی وجوہات زیادہ ممکنہ وضاحت ہیں۔

یہی دلیل logs پڑھنے پر بھی لاگو ہوتی ہے۔ journalctl system time zone کے مطابق timestamps format کرتا ہے، جبکہ journalctl --utc UTC کو force کرتا ہے۔ دو مختلف zones میں موجود دو servers ہر incident کو وقت تبدیل کرنے کی مشق بنا دیتے ہیں، اور دباؤ کے دوران کی گئی conversions ہی timeline کو غلط پڑھنے کا سبب بنتی ہیں۔ systems کو UTC پر رکھیں، timestamps کو UTC میں store کریں، اور human کے پڑھنے کے مقام پر صرف ایک بار انہیں convert کریں۔ جو شخص کسی ایک command کے لیے local reading چاہتا ہو، وہ machine کو منتقل کیے بغیر ایسا کر سکتا ہے:

TZ=Europe/Berlin date

timedatectl output میں ایک اور line اسی section سے متعلق ہے۔ RTC in local TZ کو no پڑھنا چاہیے۔ اسے yes پر set کرنا laptop پر Windows کے ساتھ dual-booting کے لیے ایک workaround ہے، لیکن server پر یہ صرف ایسا offset شامل کرتا ہے جس سے بعد میں کوئی مسئلہ پیدا ہو سکتا ہے۔ جب یہ set ہو تو timedatectl warning print کرتا ہے کہ system کو RTC time کو local time zone میں پڑھنے کے لیے configure کیا گیا ہے۔

علامت کے مطابق خرابیوں کی تشخیص

آپ کا two-factor code ایک سرور پر مسترد ہو رہا ہے۔ کسی بھی دوسری چیز کی جانچ سے پہلے گھڑی دیکھیں۔ یہ code ایسے counter سے بنتا ہے جو ہر 30 seconds بعد آگے بڑھتا ہے، اس لیے 90 seconds پیچھے رہنے والا سرور اس 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)۔ آپ کی گھڑی repository کی Release file میں موجود تاریخ سے پیچھے ہے، اور یہ duration براہِ راست بتاتی ہے کہ گھڑی کتنی پیچھے ہے۔ گھڑی درست کریں۔ اس خرابی سے بچنے کے لیے apt کی date check بند نہ کریں، کیونکہ یہی check کسی شخص کو آپ کو stale package index فراہم کرنے سے روکتی ہے۔

ہر source line unreachable state دکھاتی ہے اور Reach کی قدر 0 ہے۔ کوئی جواب نہیں دے رہا، اس لیے اپنی config کے بجائے egress دیکھیں۔ NTP outbound کے لیے UDP port 123 استعمال کرتا ہے، اور کچھ networks اسے filter یا redirect کرتے ہیں۔ sudo chronyc ntpdata ہر source کے counters دکھاتا ہے، جن میں Total TX اور Total RX شامل ہیں۔ اگر TX count بڑھتا رہے اور RX صفر رہے تو اس کا مطلب ہے کہ آپ کے packets باہر جا رہے ہیں، مگر کچھ واپس نہیں آ رہا۔ یہ آپ اور source کے درمیان موجود firewall کی طرف اشارہ کرتا ہے۔

گھڑی درست تھی، پھر اچانک آگے یا پیچھے ہو گئی۔ Host کے events ایسا کر سکتے ہیں۔ بحال کیا گیا snapshot، paused guest، یا کسی دوسرے host پر live migration، guest کے وقت کو حقیقی وقت سے پیچھے چھوڑ سکتی ہے۔ chrony اگلے poll پر اس تبدیلی کو محسوس کر کے وقت درست کرتا ہے؛ systemd-timesyncd پہلے طویل poll interval کے ختم ہونے کا انتظار کر سکتا ہے۔ systemctl is-enabled chrony سے تصدیق کریں کہ daemon boot کے وقت start ہوتا ہے، کیونکہ ہاتھ سے start کیا گیا daemon اگلے reboot کے بعد ختم ہو جاتا ہے۔

Offset معمولی ہے، لیکن کبھی settle نہیں ہوتا۔ CPU steal دیکھیں۔ جب timer interrupt مقررہ وقت پر آئے اور guest کو schedule نہ کیا جائے تو اس کے samples تاخیر سے ملتے ہیں۔ اس لیے offset converging کے بجائے بدلتا رہتا ہے۔ top، CPU line پر اسے st figure کے طور پر دکھاتا ہے۔ shared host پر CPU steal time پڑھنے میں اس number کا مطلب اور اس سے نمٹنے کے طریقے بیان کیے گئے ہیں۔

آپ نے ابھی جو certificate جاری کیا ہے، اسے not yet valid کہہ کر مسترد کیا جا رہا ہے۔ curl، SSL certificate problem: certificate is not yet valid دکھاتا ہے، اور browsers بھی اسی طرح کا message دیتے ہیں۔ Certificate درست ہے؛ اسے check کرنے والی گھڑی پیچھے ہے۔ خرابی client یا server، دونوں میں سے کسی ایک کی گھڑی میں ہو سکتی ہے، اس لیے دونوں کی جانچ کریں۔ اگر certificate جاری کرنے والے server کی گھڑی غلط ہے تو certbot اور nginx certificate guide اسی setup کے renewal حصے کی وضاحت کرتی ہے۔

اسے پہلے سے جاری checks میں شامل کریں

Time sync boot-time setting ہوتی ہے جو کئی ماہ بعد خاموشی سے fail ہو سکتی ہے۔ یہی وہ مسئلہ ہے جسے routine پکڑ لیتی ہے، لیکن memory نہیں پکڑتی۔ timedatectl اور chronyc tracking کو ایک ساتھ پڑھنے میں دو seconds لگتے ہیں۔ انہیں نئے VPS پر پہلے دس منٹ کے دوران چلائیں، اور پھر Linux server کی باقاعدہ maintenance checklist کے مطابق دوبارہ چلائیں۔ اگر آپ چاہتے ہیں کہ check خود چلے اور offset بڑھنے پر اطلاع دے، تو systemd service اور timer لکھنا ایک چھوٹی unit کے لیے مقررہ schedule پر report کرنے کا طریقہ بیان کرتا ہے۔ ایسی check daemon کے بجائے ایک مختصر script ہوتی ہے، اس لیے اسے default کے بجائے Type=oneshot درکار ہوتا ہے۔ systemd service types کا خلاصہ واضح کرتا ہے کہ غلط type استعمال کرنے سے ایسی unit بن جاتی ہے جو ایسی کامیابی report کرتی ہے جو اسے کبھی حاصل نہیں ہوئی۔

FAQ

میں کیسے جانچوں کہ میرے VPS کی گھڑی ہم وقت ہے؟

timedatectl چلائیں اور System clock synchronized لائن پڑھیں۔ یہ kernel کا اپنا flag ہے، جسے وہ daemon set کرتا ہے جو گھڑی کو discipline کر رہا ہوتا ہے؛ اس لیے 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 کی پیروی کرتا ہے۔ یہ ایسی مشین کے لیے کافی ہے جو مسلسل online رہتی ہو اور ابتدا ہی سے درست وقت کے قریب ہو۔ chrony کئی sources سے polling کرتا ہے، اختلاف رکھنے والے sources کو مسترد کرتا ہے، آپ کی گھڑی کی rate error سیکھتا ہے، اور host pause یا live migration کے بعد تیزی سے بحال ہو جاتا ہے۔ Debian یا Ubuntu پر chrony install کرنے سے systemd-timesyncd خودکار طور پر ہٹ جاتا ہے، کیونکہ دونوں packages time-daemon فراہم کرتے ہیں۔ ایک وقت میں دو time daemons کبھی نہ چلائیں۔

میرے TOTP codes ایک server پر ناکام کیوں ہوتے ہیں، جبکہ باقی ہر جگہ کام کرتے ہیں؟

کیونکہ TOTP code موجودہ وقت کا function ہوتا ہے۔ یہ code ایک ایسے counter سے بنتا ہے جو ہر 30 seconds بعد آگے بڑھتا ہے، اس لیے server اور آپ کے phone کو اس step پر متفق ہونا چاہیے جس میں وہ موجود ہیں۔ زیادہ تر verifiers دونوں اطراف ایک ایک step قبول کرتے ہیں، جس سے ہر سمت تقریباً آدھے منٹ کی گنجائش ملتی ہے۔ اس server پر timedatectl چیک کریں۔ اگر System clock synchronized کی قدر no ہو تو time sync درست کریں؛ shared secret تبدیل کیے بغیر codes دوبارہ مطابقت رکھنے لگیں گے۔

کیا میں Docker container کے اندر وقت مقرر کر سکتا ہوں؟

نہیں، اور اس کی ضرورت بھی نہیں۔ Container host کا CLOCK_REALTIME share کرتا ہے، کیونکہ Linux time namespaces صرف monotonic اور boot-time clocks کو virtualise کرتے ہیں۔ غیر مراعات یافتہ container کو date: cannot set date: Operation not permitted ملتا ہے، جبکہ CAP_SYS_TIME شامل کرنے سے اسے اپنی الگ گھڑی نہیں ملتی بلکہ وہ host کی گھڑی تبدیل کر سکتا ہے۔ اس کے بجائے host کو sync کریں۔ Container کے اندر مختلف local time دراصل time zone setting ہوتی ہے، اس لیے container environment میں TZ set کریں۔

Server کو UTC استعمال کرنا چاہیے یا local time؟

UTC استعمال کریں، اور local time صرف اس وقت لاگو کریں جب کوئی شخص output پڑھ رہا ہو۔ UTC daylight saving کے لیے کبھی تبدیل نہیں ہوتا، اس لیے daily job پورا سال روزانہ ایک بار چلتا ہے اور مختلف servers کے timestamps کسی conversion کے بغیر ایک دوسرے سے align رہتے ہیں۔ اسے sudo timedatectl set-timezone UTC سے set کریں۔ جو شخص local reading چاہتا ہو وہ کسی ایک command کے آغاز میں prefix لگا سکتا ہے، مثلاً TZ=America/New_York date؛ اس سے system clock میں کوئی تبدیلی نہیں ہوتی۔