هي ننڍڙو ڪم هڪ جمعه جي منجهند جو ٿيو ۽ 2-3 منٽن جو وقت وٺڻ گهرجي. عام طور تي، هميشه وانگر.
هڪ ساٿي مون کي پنهنجي سرور تي اسڪرپٽ کي درست ڪرڻ لاءِ چيو. مون اهو ڪيو، ان کي هن جي حوالي ڪيو ۽ اڻڄاڻ طور تي ڇڏي ڏنو: "وقت 5 منٽ تيز آهي." اچو ته سرور کي هم وقت سازي پاڻ سنڀالي. اڌ ڪلاڪ، هڪ ڪلاڪ گذري ويو، ۽ هو اڃا تائين گونگا ۽ خاموشيء سان لعنت ڪئي.
”بيوقوف! - مون سوچيو، سرور ڪنسول ڏانهن سوئچ ڪندي - ٺيڪ، مان ڪجهه منٽن لاء وقف وٺندس.
اچو ته ڏسون ntp، rdate، sdwdate انسٽال ٿيل نه آهي ٽائيم سن ڊي معذور ۽ نه هلندڙ.
# 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
ٻيهر هم وقت سازي ڪرڻ غائب ٿي ويو ۽ ٻي صورت ۾ لاگز پراڻي آهن.
نتيجن جي جانچ ڪندي ٽي سي پيمپ پورٽ 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، ٽائيم، 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 - اسان جي پرازي ملي وئي آهي. ان جي "بدسلوڪي" رويي جي باوجود، مشروط رسائي سسٽم کي رد ڪرڻ ناممڪن آهي، پر مان اڃا تائين ڄاڻڻ چاهيان ٿو آسڪيم، WTF؟
جواب جلدي ۾ ملي ٿو :
#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