دا وړه دنده د جمعې په ماسپښین راپورته شوه او باید 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
بیا همغږي کول ورک شوي او که نه نو لاګونه اصلي دي.
د پایلو چک کول tcpdump په ټولو انٹرفیسونو کې په 123 بندر کې. هیڅ غوښتنه نشته، مګر وخت لاهم تیریږي.
دویمه تېروتنه. رش
د کاري اونۍ پای ته یو ساعت پاتې دی، او زه نه غواړم د اونۍ پای ته د یوې کوچنۍ نا حل شوې ستونزې سره پریږدم (په کوډ کې وخت ته پام مه کوئ، مقاله په راتلونکو ورځو کې لیکل شوې وه ).
او دلته بیا، د علت په لټه کې، ما هڅه پیل کړه چې د پایلې لپاره توضیحاتو سره راشي. زه وایم "اختیار" ځکه چې مهمه نده چې د پایلې لپاره توضیحات څومره منطقي وي ، دا د ستونزې حل کولو لپاره نیمګړتیا ده.
دا سرور یو سټیمینګ سرور دی او د DVB-S2 جریان IP ته بدلوي. د DVB-S جریان د وخت سټیمپونه لري ، نو ترلاسه کونکي ، ملټي پلیکسرونه ، سکریمبلرونه او تلویزیونونه اکثرا دوی د سیسټم ساعت همغږي کولو لپاره کاروي. د DVB-S بورډ ډرایورونه په کرنل کې جوړ شوي، نو د دې ډاډ ترلاسه کولو لپاره ترټولو ګړندۍ لاره چې د DVB-S2 جریان لرې شوی دی د "پلیټونو" څخه راځي کیبلونه منحل کول دي. خوشبختانه، سرور د دیوال تر شا دی، نو همداسې وي.
البته، که چیرې په لاګونو کې هغه څه شتون ولري چې باید شتون ولري، دا به نه و پیښ شوي، مګر د دې په اړه نور بیا، د مقالې په پای کې.
ښه، ځکه چې موږ دمخه د سپوږمکۍ ټول سیګنالونه لیرې کړي دي، موږ به ځمکني سیګنالونه هم لیرې کړو - په ورته وخت کې موږ د شبکې ټول کیبلونه وباسو. سرور له بهرنۍ نړۍ څخه قطع کیږي او په بشپړ ډول په خپلواکه توګه کار کوي، مګر د سیسټم ساعت لاهم په چټکۍ کې دی.
د کار اونۍ پای ته رسیدلې، او د نیټې / وخت مسله پخپله مهمه نه ده، نو تاسو کولی شئ یوازې کور ته لاړ شئ، مګر دلته زه یوه نوې تېروتنه کوم.
دریمه تېروتنه. مشاورین
هیڅکله نه! هیڅکله په فورمونو او عمومي تخصص (a la stackoverflow) سایټونو کې پوښتنې مه کوئ که ځواب یې د ګوګل د لومړي مخ مطالعې او د یو سړي پا pageې لوستلو څخه ډیر څه ته اړتیا ولري.
دوی به تاسو بیرته ګوګل ته واستوي، ورته سړی ولولئ او په مشهور ډول به د فورم / سایټ قواعد تشریح کړي، مګر تاسو ته به ځواب نه درکړي.
دلته ځینې موخې عوامل دي:
- له تا پرته بل څوک نه شي کولای چې په ستونزه هم پوه شي؛
- هیڅوک نشي کولی ستاسو په څیر ورته شرایطو کې ازموینې ترسره کړي
او موضوعي:
- تاسو ممکن د ستونزې د حل لپاره ټول معلومات ونه ورکوئ، ځکه چې تاسو دمخه د "سمه" لوري سره راغلی یاست او د مسلې جوهر وړاندې کوئ چې تمرکز یې کوي؛
- فورمین (منتظم، زوړ ټایمر، مدیر) تل سم وي، که فورمین غلط وي ... ښه، تاسو پوهیږئ ...
که، د تبصرو په ځواب کې، تاسو د سانسور شوي لغتونو په حدودو کې پاتې یاست، نو تاسو قوي اعصاب لرئ.
پریکړه
اړتیا نشته چې کارونه په ساده او پیچلي ویشل شي.
موږ په خپلو تجربو، احصایو، مشاورینو تکیه کول بندوو او د پای پایلې "توضیح" نه پیل کوو، مګر په دوامداره توګه د دلیل په لټه کې یو.
څرنګه چې یو څوک وخت ټاکي، د اړوند سیسټم زنګ باید واقع شي.
لکه څنګه چې د سافټویر اسنادو کې غوره اسناد سرچینې دي، نو د سیسټم اداره کولو کې غوره معاون پلټنه ده، زموږ په قضیه کې پلټنه.
د شک یوه شیبهزه د مانا له لارې لاړم، مګر په بشپړ ډول ډاډه نه وم چې په لینکس کې وخت یوازې ټاکل کیدی شي 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 -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. دا په پورتني راپور کې پای ته ورسید ځکه چې اورورپورټ محصول د نیټې له مخې ترتیب کړی کله چې له بائنری څخه بدلیږي ، او پیښه په هغه وخت کې رامینځته شوه چې موږ یې تنظیم کړو نیټه "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