VPS کی گھڑی میں drift: وجہ اور درست کرنے کا طریقہ

آپ کے VPS کی گھڑی میں drift کیوں آتی ہے

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

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

غلط clock حقیقت میں کیا خراب کرتا ہے

• TOTP (time-based one-time password) کے two-factor codes آپس میں match نہیں ہوتے، اس لیے آپ ایسے server سے locked out ہو جاتے ہیں جس کا password اور key دونوں درست ہوں۔
• ایک منٹ پہلے جاری کیا گیا certificate reject ہو جاتا ہے، اور 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 کام غلط وقت پر چلتا ہے، اور clock کے jump کرنے سے ایک job دو بار چل سکتی ہے جبکہ دوسری skip ہو سکتی ہے۔
• دو servers کے 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 قبول کرتے ہیں۔ ہر سمت میں آدھے منٹ کی error ہی پورا budget ہے۔ Kerberos کہیں زیادہ forgiving ہے اور اس میں default skew allowance 300 seconds ہے۔ Certificate بالکل forgiving نہیں ہوتا: اسے fixed instants کے مقابل 0 seconds کی grace period کے ساتھ check کیا جاتا ہے، اس لیے ایک second پیچھے چلنے والی clock ایسا certificate reject کر دیتی ہے جو مکمل طور پر valid ہو۔

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

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

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

Clocksource وہ ذریعہ ہے جس سے 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 کو پڑھتا ہے، اسی لیے کسی NTP client کے بغیر بھی KVM guest کچھ وقت تک تقریباً درست رہتا ہے۔ tsc CPU کا اپنا counter ہے۔ Xen guests xen report کرتے ہیں، جبکہ Hyper-V guests ایک hyperv source report کرتے ہیں۔ اس setting کو تبدیل نہ کریں، جب تک اسے تبدیل کرنے کی کوئی measured وجہ موجود نہ ہو، کیونکہ 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 بتاتا ہے کہ system local time format کرنے کے لیے کیا استعمال کرتا ہے۔
• 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 بھی اس سے متفق ہے۔

اب معلوم کریں کہ وقت میں کتنا فرق ہے۔ اسے اپنے 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 list کے اوپر legend دکھاتا ہے، اس لیے آپ کو symbols یاد رکھنے کی ضرورت نہیں۔ زیادہ تر مفہوم دو columns میں ہوتا ہے۔ ہر line کے آغاز میں موجود state character بتاتا ہے کہ chrony اس source کی درجہ بندی کیسے کرتا ہے۔ * اس source کو mark کرتا ہے جسے وہ فی الحال استعمال کر رہا ہے، جبکہ ہر 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 واپس کرے تو اس machine پر timesyncd ذمہ دار daemon نہیں ہے۔ یہی آپ کے سوال کا جواب ہے۔

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

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

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

VPS پر chrony یا systemd-timesyncd

Ubuntu اور Debian میں by default 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 کے مستقل رجحان کو درست کرتا ہے۔ یہ ان دو حالات سے بھی تیزی سے بحال ہو جاتا ہے جو VM میں physical box کے مقابلے میں پیش آ سکتے ہیں: 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 ایک دوسرے سے متصادم ہوں گے، اور اس دوران کسی ایک کا reported 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 منٹوں کے بجائے چند seconds میں ہو جاتی ہے۔
• makestep طے کرتا ہے کہ chrony clock کو بتدریج درست کرنے کے بجائے کب فوراً آگے یا پیچھے کرے۔ grep -n makestep /etc/chrony/chrony.conf سے دیکھیں کہ آپ کی configuration میں کیا درج ہے۔ Debian اور Ubuntu کا default، makestep 1 3، اس کا مطلب رکھتا ہے: chronyd شروع ہونے کے بعد پہلی تین updates کے دوران اگر clock ایک second سے زیادہ غلط ہو تو اسے فوراً درست کریں، اور اس کے بعد صرف بتدریج correction کریں۔

اگر آپ راستے میں چھیڑ چھاڑ کے خلاف time traffic کی authentication چاہتے ہیں تو chrony 4 اور اس کے بعد کے versions NTS (network time security) support کرتے ہیں۔ پہلے chronyd -v سے اپنا version confirm کریں۔ یہ بھی یاد رکھیں کہ 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

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

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

اسی ترجیح کی وجہ سے بہت زیادہ غلط clock طویل وقت تک غلط رہ سکتی ہے۔ chrony صرف اسی window کے اندر step کرتا ہے جس کی اجازت makestep دیتا ہے۔ default طور پر یہ window daemon شروع ہونے کے بعد کی پہلی چند updates تک محدود ہوتی ہے۔ اگر chronyd ایک ہفتے سے چل رہا ہو اور پھر اسے چالیس second کا error ملے، تو وہ اسے slew کرے گا۔ چالیس second کو slew کرنے میں آپ کی مطلوبہ مدت سے کہیں زیادہ وقت لگتا ہے۔ خاموش وقت میں اسے ایک بار جان بوجھ کر force کریں:

sudo chronyc makestep
chronyc tracking

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

کنٹینرز میزبان کی گھڑی شیئر کرتے ہیں

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

اس کے چند نتائج نکلتے ہیں۔ image میں chrony یا ntpd انسٹال نہ کریں، کیونکہ بہترین صورت میں بھی اس کا کوئی اثر نہیں ہوتا۔ کسی unprivileged container کے اندر date set کرنا date: cannot set date: Operation not permitted کے ساتھ fail ہوتا ہے، کیونکہ 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 کا موازنہ ان تبدیلیوں کا احاطہ کرتا ہے جو وہ واقعی کرتا ہے۔

سرور پر UTC اور لوگوں کے لیے مقامی وقت

مشین کو UTC پر set کریں اور اسی پر رہنے دیں۔

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

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

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

TZ=Europe/Berlin date

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

علامت کے مطابق خرابیوں کی جانچ

آپ کا two-factor code ایک server پر مسترد ہو جاتا ہے۔ کسی بھی دوسری چیز کی جانچ سے پہلے clock دیکھیں۔ یہ code ایک ایسے counter سے آتا ہے جو ہر 30 seconds بعد آگے بڑھتا ہے، اس لیے 90 seconds پیچھے موجود server اس step کا code بناتا ہے جس سے آپ کا phone پہلے ہی گزر چکا ہے۔ 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 میں موجود تاریخ سے پیچھے ہے، اور یہ مدت براہ راست بتاتی ہے کہ clock کتنی پیچھے ہے۔ clock درست کریں۔ اس خرابی سے گزرنے کے لیے 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، Total TX اور Total RX سمیت ہر source کے counters دکھاتا ہے۔ اگر TX count بڑھتا رہے جبکہ RX صفر رہے، تو اس کا مطلب ہے کہ آپ کے packets باہر جا رہے ہیں لیکن کچھ واپس نہیں آ رہا۔ اس سے آپ اور source کے درمیان موجود firewall کا شبہ ہوتا ہے۔

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

Offset کم ہے لیکن کبھی مستحکم نہیں ہوتا۔ CPU steal دیکھیں۔ جو guest اپنے timer interrupt کے مقررہ وقت پر schedule نہ ہو، اس کے samples تاخیر سے آتے ہیں۔ اس لیے offset converge ہونے کے بجائے بدلتا رہتا ہے۔ 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 کرنے والی clock پیچھے ہے۔ خرابی client یا server، دونوں میں سے کسی ایک پر ہو سکتی ہے، اس لیے دونوں کی جانچ کریں۔ اگر certificate جاری کرنے والے server کی clock غلط ہے تو certbot اور nginx certificate کی رہنما دستاویز اسی setup کے renewal حصے کی وضاحت کرتی ہے۔

اسے اپنے پہلے سے چلائے جانے والے checks میں شامل کریں

وقت کی ہم آہنگی boot-time setting ہے، جو کئی ماہ بعد خاموشی سے fail ہو سکتی ہے۔ یہی وجہ ہے کہ routine اسے پکڑ لیتی ہے، جبکہ یادداشت ایسا نہیں کر پاتی۔ timedatectl اور chronyc tracking کو ایک ساتھ پڑھنے میں دو seconds لگتے ہیں۔ انہیں نئے VPS پر پہلے دس minutes کے دوران چلائیں، اور پھر باقاعدہ Linux server maintenance checklist کے مطابق کام کرتے وقت دوبارہ چلائیں۔ اگر آپ چاہتے ہیں کہ check خود چلے اور offset بڑھنے پر اطلاع دے، تو systemd service اور timer لکھنا ایک چھوٹی unit کے لیے مقررہ schedule پر report کرنے کا طریقہ بیان کرتا ہے۔

FAQ

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

timedatectl چلائیں اور System clock synchronized لائن پڑھیں۔ یہ kernel کا اپنا flag ہے، جسے گھڑی کو منظم کرنے والا daemon set کرتا ہے، اس لیے chrony والی مشین پر yes کا NTP service: n/a کے ساتھ آنا معمول اور درست ہے۔ خرابی کی مقدار جاننے کے لیے chronyc tracking چلائیں اور System time پڑھیں، یا اگر systemd-timesyncd ذمہ دار ہے تو timedatectl timesync-status چلائیں اور Offset پڑھیں۔ مشین کے باہر موجود کسی ذریعے کے ساتھ جانچ کے لیے date -u کا موازنہ کسی بھی HTTPS سائٹ سے موصول ہونے والے 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 نہ چلائیں۔

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

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

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

نہیں، اور اس کی ضرورت بھی نہیں ہے۔ container host کا CLOCK_REALTIME share کرتا ہے، کیونکہ Linux time namespaces صرف monotonic اور boot-time clocks کو virtualise کرتے ہیں۔ ایک unprivileged 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 میں کوئی تبدیلی نہیں ہوتی۔