یہ معمولی کام ایک جمعہ کی دوپہر کو ہوا اور اس میں 2-3 منٹ کا وقت ہونا چاہیے تھا۔ عام طور پر، ہمیشہ کی طرح۔
ایک ساتھی نے مجھ سے اس کے سرور پر اسکرپٹ کو ٹھیک کرنے کو کہا۔ میں نے یہ کیا، اسے اس کے حوالے کیا اور نادانستہ طور پر کہا: "وقت 5 منٹ تیز ہے۔" سرور کو مطابقت پذیری کو خود ہینڈل کرنے دیں۔ آدھا گھنٹہ، ایک گھنٹہ گزر گیا، اور وہ اب بھی پھونک پھونک کر خاموشی سے کوستا رہا۔
"بے وقوف! — میں نے سوچا، سرور کنسول پر سوئچ کرتے ہوئے — ٹھیک ہے، میں مزید چند منٹوں کے لیے وقفہ لوں گا۔
چلو دیکھتے ہیں ntp، rdate، sdwdate انسٹال نہیں timesyncd غیر فعال اور نہیں چل رہا ہے۔
# timedatectl
Local time: Sun 2019-08-25 20:44:39 +03
Universal time: Sun 2019-08-25 17:44:39 UTC
RTC time: Sun 2019-08-25 17:39:52
Time zone: Europe/Minsk (+03, +0300)
NTP enabled: no
NTP synchronized: no
RTC in local TZ: no
DST active: n/a
یہاں میں فوری طور پر نوٹ کروں گا کہ ہارڈ ویئر کا وقت درست ہے: مزید نیویگیٹ کرنا آسان ہوگا۔
یہیں سے غلطیوں کا سلسلہ شروع ہوا۔
پہلی غلطی۔ خود اعتمادی
کلک-کلک...
# systemctl enable systemd-timesyncd.service && systemctl start systemd-timesyncd.service && ntpdate 0.ru.pool.ntp.org && timedatectl set-ntp on && timedatectl
25 Aug 21:00:10 ntpdate[28114]: adjust time server 195.210.189.106 offset -249.015251 sec
Local time: Sun 2019-08-25 21:00:10 +03
Universal time: Sun 2019-08-25 18:00:10 UTC
RTC time: Sun 2019-08-25 18:00:10
Time zone: Europe/Minsk (+03, +0300)
NTP enabled: yes
NTP synchronized: yes
RTC in local TZ: no
DST active: n/a
سب کچھ ٹھیک ہے، وقت مطابقت پذیر ہے، سسٹم کا وقت ہارڈ ویئر سے ملتا ہے۔ "یہ لے لو،" میں نے کہا اور اپنے کاروبار میں واپس آ گیا۔
"کیا لیں؟ - ساتھی ناراض تھا. "یہ ایک ہی وقت ہے!"
جتنا زیادہ آپ عام مسائل کو حل کرتے ہیں، آپ کی سوچ اتنی ہی زیادہ چمکتی جاتی ہے اور آپ اب یہ نہیں سوچتے کہ سوویں یا ہزارویں صورت حال مختلف ہوگی، لیکن اس بار نہیں۔
# timedatectl
Local time: Sun 2019-08-25 21:09:15 +03
Universal time: Sun 2019-08-25 18:09:15 UTC
RTC time: Sun 2019-08-25 18:05:04
Time zone: Europe/Minsk (+03, +0300)
NTP enabled: yes
NTP synchronized: no
RTC in local TZ: no
DST active: n/a
سسٹم کا وقت پھر غلط ہے۔
دوبارہ کوشش کرتے ہیں:
# ntpdate 0.ru.pool.ntp.org && timedatectl && sleep 1 && timedatectl
25 Aug 21:07:37 ntpdate[30350]: step time server 89.175.20.7 offset -249.220828 sec
Local time: Sun 2019-08-25 21:07:37 +03
Universal time: Sun 2019-08-25 18:07:37 UTC
RTC time: Sun 2019-08-25 18:07:37
Time zone: Europe/Minsk (+03, +0300)
NTP enabled: yes
NTP synchronized: yes
RTC in local TZ: no
DST active: n/a
Local time: Sun 2019-08-25 21:11:46 +03
Universal time: Sun 2019-08-25 18:11:46 UTC
RTC time: Sun 2019-08-25 18:07:37
Time zone: Europe/Minsk (+03, +0300)
NTP enabled: yes
NTP synchronized: no
RTC in local TZ: no
DST active: n/a
آئیے اسے مختلف طریقے سے کریں:
# date -s "2019-08-25 21:10:30" && date && sleep 1 && timedatectl
Sun Aug 25 21:10:30 +03 2019
Sun Aug 25 21:10:30 +03 2019
Local time: Sun 2019-08-25 21:14:36 +03
Universal time: Sun 2019-08-25 18:14:36 UTC
RTC time: Sun 2019-08-25 18:10:30
Time zone: Europe/Minsk (+03, +0300)
NTP enabled: yes
NTP synchronized: no
RTC in local TZ: no
DST active: n/a
اور اس طرح:
# hwclock --hctosys && timedatectl && sleep 1 && timedatectl
Local time: Sun 2019-08-25 21:11:31 +03
Universal time: Sun 2019-08-25 18:11:31 UTC
RTC time: Sun 2019-08-25 18:11:31
Time zone: Europe/Minsk (+03, +0300)
NTP enabled: yes
NTP synchronized: yes
RTC in local TZ: no
DST active: n/a
Local time: Sun 2019-08-25 21:15:36 +03
Universal time: Sun 2019-08-25 18:15:36 UTC
RTC time: Sun 2019-08-25 18:11:32
Time zone: Europe/Minsk (+03, +0300)
NTP enabled: yes
NTP synchronized: no
RTC in local TZ: no
DST active: n/a
وقت ایک الگ سیکنڈ کے لئے مقرر کیا جاتا ہے، اور فوری طور پر دوبارہ "جلد" شروع ہوتا ہے.
ایک ہی وقت میں، نوشتہ جات میں، اس طرح کی دستی تبدیلی کے وقت، ہم صرف سسٹم رپورٹس دیکھتے ہیں کہ وقت بالترتیب، صحیح/غلط سمت میں اور کبھی کبھار تبدیل ہوا ہے۔ دوبارہ مطابقت پذیری systemd-timesyncd سے۔
Aug 25 21:18:51 wisi systemd[1]: Time has been changed
Aug 25 21:18:51 wisi systemd-timesyncd[29258]: System time changed. Resyncing.
Aug 25 21:18:51 wisi systemd[1187]: Time has been changed
Aug 25 21:18:51 wisi systemd[1]: Time has been changed
Aug 25 21:18:51 wisi systemd[1187]: Time has been changed
یہاں
# ps afx | grep "[1]187"
1187 ? Ss 0:02 /lib/systemd/systemd --user
اس مقام پر، اس کی وجہ تلاش کرنا پہلے سے ہی ضروری تھا، لیکن 18 سال سے زیادہ انتظامیہ کے دماغ نے "وقت" کی غلطیوں کے اعدادوشمار جمع کیے ہیں اور عادت سے ہٹ کر دوبارہ ہم آہنگی کو مورد الزام ٹھہرایا ہے۔
آئیے اسے مکمل طور پر بند کردیں۔
# timedatectl set-ntp off && systemctl stop systemd-timesyncd.service
# hwclock --hctosys && timedatectl && sleep 1 && timedatectl
Local time: Sun 2019-08-25 21:25:40 +03
Universal time: Sun 2019-08-25 18:25:40 UTC
RTC time: Sun 2019-08-25 18:25:40
Time zone: Europe/Minsk (+03, +0300)
NTP enabled: no
NTP synchronized: no
RTC in local TZ: no
DST active: n/a
Local time: Sun 2019-08-25 21:29:31 +03
Universal time: Sun 2019-08-25 18:29:31 UTC
RTC time: Sun 2019-08-25 18:25:41
Time zone: Europe/Minsk (+03, +0300)
NTP enabled: no
NTP synchronized: no
RTC in local TZ: no
DST active: n/a
اور نوشتہ جات میں
Aug 25 21:25:40 wisi systemd[1]: Time has been changed
Aug 25 21:25:40 wisi systemd[1187]: Time has been changed
Aug 25 21:29:30 wisi systemd[1]: Time has been changed
Aug 25 21:29:30 wisi systemd[1187]: Time has been changed
دوبارہ مطابقت پذیری غائب ہو گیا اور دوسری صورت میں نوشتہ جات قدیم ہیں۔
نتائج کی جانچ کر رہا ہے۔ tcpdomp تمام انٹرفیس پر پورٹ 123 پر۔ کوئی درخواستیں نہیں ہیں، لیکن وقت اب بھی بھاگ رہا ہے.
غلطی دو۔ رش
کام کے ہفتے کے اختتام میں ایک گھنٹہ باقی ہے، اور میں ہفتے کے آخر میں ایک معمولی حل طلب مسئلہ کے ساتھ نہیں جانا چاہتا (کوڈ میں وقت پر توجہ نہ دیں، مضمون اگلے دنوں میں لکھا گیا تھا )۔
اور یہاں ایک بار پھر وجہ تلاش کرنے کے بجائے نتیجہ کی وضاحت کے ساتھ سامنے آنے کی کوشش کرنے لگا۔ میں "ایجاد" کہتا ہوں کیونکہ اس سے کوئی فرق نہیں پڑتا ہے کہ نتیجہ کی وضاحت کتنی ہی منطقی ہو، یہ مسئلہ کو حل کرنے کے لیے ایک ناقص طریقہ ہے۔
یہ سرور ایک سٹریمنگ سرور ہے اور DVB-S2 سٹریم کو IP میں تبدیل کرتا ہے۔ DVB-S سٹریم ٹائم اسٹیمپ پر مشتمل ہے، لہذا ریسیورز، ملٹی پلیکسرز، اسکرمبلر اور ٹیلی ویژن اکثر انہیں سسٹم کلاک کو سنکرونائز کرنے کے لیے استعمال کرتے ہیں۔ DVB-S بورڈ ڈرائیور دانا میں بنائے گئے ہیں، اس لیے DVB-S2 سٹریم کو ہٹانے کو یقینی بنانے کا تیز ترین طریقہ یہ ہے کہ "پلیٹ" سے آنے والی کیبلز کو منقطع کر دیا جائے۔ خوش قسمتی سے، سرور دیوار کے پیچھے ہے، تو ایسا ہی ہو۔
بلاشبہ، اگر نوشتہ جات میں وہ ہوتا جو وہاں ہونا چاہیے تھا، تو ایسا نہ ہوتا، لیکن اس پر مزید، مضمون کے آخر میں۔
ٹھیک ہے، چونکہ ہم نے پہلے ہی تمام سیٹلائٹ سگنلز ہٹا دیے ہیں، اس لیے ہم زمینی سگنلز کو بھی ہٹا دیں گے - ساتھ ہی ہم تمام نیٹ ورک کیبلز کو بھی نکال دیں گے۔ سرور بیرونی دنیا سے منقطع ہو جاتا ہے اور مکمل طور پر خود مختاری سے کام کرتا ہے، لیکن سسٹم کلاک ابھی بھی جلدی میں ہے۔
کام کا ہفتہ ختم ہو گیا ہے، اور تاریخ/وقت کا مسئلہ بذات خود اہم نہیں ہے، اس لیے آپ گھر جا سکتے ہیں، لیکن یہاں میں ایک نئی غلطی کر رہا ہوں۔
غلطی تین۔ مشیر
کبھی نہیں! فورمز اور جنرل اسپیشلائزڈ (a la stackoverflow) سائٹس پر کبھی بھی سوالات نہ پوچھیں اگر اس کے جواب کے لیے گوگل کے پہلے صفحے کا مطالعہ کرنے اور ایک مین پیج کو پڑھنے سے زیادہ کی ضرورت ہے۔
وہ آپ کو گوگل پر واپس بھیجیں گے، اسی آدمی کو پڑھیں گے اور فورم/سائٹ کے قواعد کی مقبولیت کی وضاحت کریں گے، لیکن آپ کو کوئی جواب نہیں دیں گے۔
یہاں کچھ معروضی عوامل ہیں:
- آپ کے علاوہ کوئی بھی مسئلہ نہیں جان سکتا۔
- کوئی بھی آپ کی طرح کے حالات میں ٹیسٹ نہیں کر سکتا
اور موضوعی:
- ہو سکتا ہے کہ آپ مسئلے کو حل کرنے کے لیے تمام معلومات نہ دیں، کیونکہ آپ پہلے ہی "صحیح" سمت لے کر آئے ہیں اور اس پر توجہ مرکوز کرتے ہوئے مسئلے کا نچوڑ پیش کر رہے ہیں۔
- فورمین (ماڈریٹر، اولڈ ٹائمر، ایڈمن) ہمیشہ درست ہوتا ہے، اگر فورمین غلط ہے... ٹھیک ہے، آپ جانتے ہیں...
اگر، تبصروں کا جواب دیتے وقت، آپ سنسر شدہ الفاظ کی حدود میں رہے، تو آپ کے اعصاب مضبوط ہیں۔
حل
کاموں کو آسان اور پیچیدہ میں تقسیم کرنے کی ضرورت نہیں ہے۔
ہم اپنے تجربے، اعدادوشمار، مشیروں پر بھروسہ کرنا چھوڑ دیتے ہیں اور حتمی نتیجہ کی "وضاحت" نہیں کرتے، بلکہ مسلسل وجہ تلاش کرتے ہیں۔
چونکہ کوئی وقت مقرر کرتا ہے، اس لیے متعلقہ سسٹم کال ضرور ہونی چاہیے۔
جس طرح سافٹ ویئر دستاویزات میں بہترین دستاویزات ذرائع ہوتے ہیں، اسی طرح سسٹم ایڈمنسٹریشن میں بہترین اسسٹنٹ آڈٹ ہوتا ہے، ہمارے معاملے میں آڈٹ.
شک کا ایک لمحہمیں منا سے گزرا، لیکن مکمل طور پر یقین نہیں تھا کہ لینکس میں صرف وقت مقرر کیا جا سکتا ہے clock_settime и دن کا وقتلہذا پہلے ٹیسٹ کے لیے میں نے تمام "مناسب" کالز کا انتخاب کیا:
# man syscalls | col | grep -F '(2)' | grep -vE '(:|;)' | grep -E '(time|date|clock)' | sed "s/(2).*//" | xargs -I SYSCALL echo "-S SYSCALL " | xargs echo
-S adjtimex -S clock_adjtime -S clock_getres -S clock_gettime -S clock_nanosleep -S clock_settime -S futimesat -S getitimer -S gettimeofday -S mq_timedreceive -S mq_timedsend -S rt_sigtimedwait -S s390_runtime_instr -S setitimer -S settimeofday -S stime -S time -S timer_create -S timer_delete -S timer_getoverrun -S timer_gettime -S timer_settime -S timerfd_create -S timerfd_gettime -S timerfd_settime -S times -S utime -S utimensat -S utimes
اور ضائع کرنا s390_runtime_instr، stime، timerfd_create، کونسا auditctl اسے نہیں پہچانا، ابتدائی طور پر فارم میں ایک آڈٹ شروع کیا:
auditctl -a exit,always -S adjtimex -S clock_adjtime -S clock_getres -S clock_nanosleep -S clock_settime -S futimesat -S getitimer -S gettimeofday -S mq_timedreceive -S mq_timedsend -S rt_sigtimedwait -S semtimedop -S setitimer -S settimeofday -S time -S timer_create -S timer_delete -S timer_getoverrun -S timer_gettime -S timer_settime -S timerfd_gettime -S timerfd_settime -S times -S utime -S utimensat -S utimesاس بات کو یقینی بنانے کے بعد کہ لاگ ان مقامات میں کوئی اور لاگز نہیں ہیں جن میں میری دلچسپی ہے۔ سسکلز ان دونوں کے علاوہ، میں نے ان کو مزید استعمال کیا۔
سسٹم کال آڈٹ چل رہا ہے۔ clock_settime и دن کا وقت اور تاریخ کو تبدیل کرنے کی کوشش کریں:
# auditctl -a exit,always -S clock_settime -S settimeofday && date -s "2019-08-22 12:10:00" && sleep 5 && auditctl -D
پانچ سیکنڈ کی تاخیر شامل کی جاتی ہے تاکہ ہمارے "پرجیوی" وقت کو درست کرنے کی ضمانت ہو۔
آئیے دیکھتے ہیں رپورٹ:
# aureport -s -i
Syscall Report
=======================================
# date time syscall pid comm auid event
=======================================
Warning - freq is non-zero and incremental flushing not selected.
1. 08/22/2019 12:10:00 settimeofday 3088 chkcache_proces root 479630
2. 08/26/2019 09:37:06 clock_settime 1538 date root 479629
یہاں ہم دیکھتے ہیں ہمارے تاریخ اور ہمارے لئے نامعلوم chkcache_processes. یہ اوپر کی رپورٹ میں ختم ہوا کیونکہ aureport نے بائنری سے تبدیل کرتے وقت آؤٹ پٹ کو تاریخ کے لحاظ سے ترتیب دیا تھا، اور واقعہ اس وقت پیش آیا جب ہم نے سیٹ کیا تھا۔ تاریخ "2019-08-22 12:10:00".
اسے کس نے جنم دیا؟
# ausearch -sc settimeofday --comm "chkcache_proces"
----
time->Thu Aug 22 12:10:00 2019
type=PROCTITLE msg=audit(1566465000.000:479630): proctitle="/usr/local/bin/oscam"
type=SYSCALL msg=audit(1566465000.000:479630): arch=c000003e syscall=164 success=yes exit=0 a0=7fde0dfc6e60 a1=0 a2=136cf a3=713ba56 items=0 ppid=3081 pid=3088 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts20 ses=68149 comm="chkcache_proces" exe="/usr/local/bin/oscam" key=(null)
/usr/local/bin/oscam - ہمارا پرجیوی مل گیا ہے۔ اس کے "بد نیتی پر مبنی" رویے کے باوجود، مشروط رسائی کے نظام سے انکار کرنا ناممکن ہے، لیکن میں پھر بھی جاننا چاہوں گا oscam، ڈبلیو ٹی ایف؟
اس کا جواب جلدی سے مل جاتا ہے۔ :
#if defined(CLOCKFIX)
if (tv.tv_sec > lasttime.tv_sec || (tv.tv_sec == lasttime.tv_sec && tv.tv_usec >= lasttime.tv_usec)) // check for time issues!
{
lasttime = tv; // register this valid time
}
else
{
tv = lasttime;
settimeofday(&tv, NULL); // set time back to last known valid time
//fprintf(stderr, "*** WARNING: BAD TIME AFFECTING WHOLE OSCAM ECM HANDLING, SYSTEMTIME SET TO LAST KNOWN VALID TIME **** n");
}
یہاں کتنا پیارا لگ رہا ہے۔ تبصرہ کیا لائن انتباہ...
ماخذ: www.habr.com