Այս չնչին խնդիրն առաջացավ ուրբաթ օրվա երկրորդ կեսին և պետք է տևեր 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
Կրկին համաժամացում անհետացել է, իսկ հակառակ դեպքում գերանները անարատ են:
Ստուգելով եզրակացությունները tcpdump 123 նավահանգստի վրա բոլոր ինտերֆեյսներում: Հարցումներ չկան, բայց ժամանակը դեռ փախչում է։
Սխալ երկու. Շտապում
Աշխատանքային շաբաթվա ավարտին մեկ ժամ է մնացել, և ես չեմ ուզում հանգստյան օրեր մեկնել չնչին չլուծված խնդիրով (օրենսգրքում նշված ժամին ուշադրություն մի դարձրեք, հոդվածը գրվել է հաջորդ օրերին. ).
Եվ այստեղ նորից, պատճառը փնտրելու փոխարեն, սկսեցի փորձել արդյունքի բացատրություն տալ։ Ես ասում եմ «հորինել», քանի որ որքան էլ տրամաբանական լինի արդյունքի բացատրությունը, դա խնդրի լուծման թերի մոտեցում է։
Այս սերվերը հոսքային սերվեր է և փոխակերպում է DVB-S2 հոսքը IP-ի: DVB-S հոսքը պարունակում է ժամանակի դրոշմակնիքներ, ուստի ընդունիչները, մուլտիպլեքսորները, խառնիչները և հեռուստացույցները հաճախ օգտագործում են դրանք՝ համակարգի ժամացույցը համաժամեցնելու համար: DVB-S տախտակի դրայվերները ներկառուցված են միջուկում, ուստի DVB-S2 հոսքի հեռացումն ապահովելու ամենաարագ ճանապարհը «սալերից» եկող մալուխների անջատումն է: Բարեբախտաբար, սերվերը պատի հետևում է, այդպես էլ լինի:
Իհարկե, եթե տեղեկամատյանները պարունակեին այն, ինչ պետք է այնտեղ լիներ, դա տեղի չէր ունենա, բայց ավելին դրա մասին՝ կրկին հոդվածի վերջում։
Դե, քանի որ մենք արդեն հեռացրել ենք բոլոր արբանյակային ազդանշանները, մենք կհեռացնենք նաև ցամաքայինները, միևնույն ժամանակ մենք հանում ենք բոլոր ցանցային մալուխները: Սերվերը կտրվում է արտաքին աշխարհից և աշխատում է ամբողջովին ինքնուրույն, սակայն համակարգի ժամացույցը դեռ շտապում է։
Աշխատանքային շաբաթն ավարտվեց, և ամսաթիվը/ժամը ինքնին կարևոր չէ, այնպես որ կարող եք պարզապես տուն գնալ, բայց այստեղ ես նոր սխալ եմ թույլ տալիս:
Սխալ երեք. Խորհրդականներ
Երբեք! Երբեք հարցեր մի տվեք ֆորումներին և ընդհանուր մասնագիտացված (a la stackoverflow) կայքերին, եթե դրա պատասխանը պահանջում է ավելին, քան Google-ի առաջին էջն ուսումնասիրելը և մեկ մարդու էջը կարդալը:
Նրանք քեզ հետ կուղարկեն Google, կկարդան նույն մարդուն և հանրաճանաչ կերպով կբացատրեն ֆորումի/կայքի կանոնները, բայց քեզ պատասխան չեն տա։
Ահա մի քանի օբյեկտիվ գործոններ.
- Ձեզնից բացի ոչ ոք չի կարող նաև իմանալ խնդիրը.
- ոչ ոք չի կարող թեստեր անցկացնել նույն պայմաններում, ինչ ձերն է
և սուբյեկտիվ:
- Դուք կարող եք չտալ ամբողջ ներդրումը խնդրի լուծման համար, քանի որ արդեն «ճիշտ» ուղղություն եք տվել և դրա վրա կենտրոնանալով ներկայացնում եք հարցի էությունը.
- վարպետը (մոդերատոր, հնաբնակ, ադմին) միշտ ճիշտ է, եթե վարպետը սխալ է... դե գիտես...
Եթե մեկնաբանություններին պատասխանելիս մնացել ես գրաքննված բառապաշարի սահմաններում, ուրեմն ամուր նյարդեր ունես։
որոշում
Կարիք չկա առաջադրանքները բաժանել պարզի և բարդի։
Մենք դադարում ենք ապավինել մեր փորձին, վիճակագրությանը, խորհրդատուներին և սկսում ենք ոչ թե «բացատրել» վերջնական արդյունքը, այլ հետևողականորեն փնտրել պատճառը։
Քանի որ ինչ-որ մեկը սահմանում է ժամանակը, համապատասխան համակարգային զանգը պետք է տեղի ունենա:
Ինչպես ծրագրային փաստաթղթերում լավագույն փաստաթղթերը աղբյուրներն են, այնպես էլ համակարգի կառավարման մեջ լավագույն օգնականը աուդիտն է, մեր դեպքում աուդիտի ենթարկված.
Կասկածի մի պահԵս անցա մանան, բայց լիովին վստահ չէի, որ Linux-ում ժամանակը կարող է սահմանվել միայն 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Համոզվելուց հետո, որ ինձ հետաքրքրող տեղեկամատյաններում այլ տեղեկամատյաններ չկան syscals Բացի այս երկուսից, ես միայն դրանք օգտագործեցի հետագա։
Համակարգային զանգերի աուդիտի իրականացում 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");
}
Որքան գեղեցիկ է այն այստեղ մեկնաբանեց տող նախազգուշացում...
Source: www.habr.com