Kjo detyrë triviale u shfaq një nga ditët e premte dhe duhej të merrte 2-3 minuta. Në përgjithësi, si gjithmonë.
Kolegu më kërkoi të rregulloja skriptin në serverin e tij. E bëra, ia dorëzova dhe pa dashje thashë: «Koha po shpejton me 5 minuta». Serveri i tij, le ta menaxhojë vetë me sinkronizimin. Kaluan gjysmë ore, një orë, por ai vazhdonte të frynte e të thoshte fjalë të pista.
«Budalla! — mendova, duke kaluar në konsolë сервера — mirë, do të shkëputem edhe për disa minuta.»
Po shohim, ntp, rdate, sdwdate nuk janë të instaluara, timesyncd është i çaktivizuar dhe nuk është në funksion.
# 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
Këtu do të theksoj menjëherë se koha harduerike është e saktë: kjo do të ndihmojë më vonë.
Këtu filloi një seri gabimesh.
Gabimi i parë. Besimi në vetvete
Klak-klak…
# 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
Gjithçka është mirë, koha është sinkronizuar, sistemi përputhet me harduerin. «Merr», — thashë dhe u ktheva tek punët e mia.
«Çfarë të marrë? — protestoi kolegu. — Koha është e njëjtë!»
Sa më shumë zgjidhni detyra tipike aq më shumë mendimi bëhet i kufizuar dhe nuk mendoni se situata e njëqindta apo e njëmijëta do të jetë ndryshe, por jo këtë herë.
# 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
Koha e sistemit është përsëri e gabuar.
Le të provojmë përsëri:
# 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
Të bëjmë ndryshe:
# 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
Ja kështu:
# 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
Koha vendoset për një çast, dhe papritmas fillon përsëri të «shpejtojë».
Ndërkohë, në log, në momentin e këtij ndryshimi manual, shohim vetëm raportet e sistemit, që koha është ndërruar, përkatësisht në drejtim të saktë / të gabuar dhe herë pas here Resyncing nga systemd-timesyncd.
Aug 25 21:18:51 wisi systemd[1]: Koha është ndërruar
Aug 25 21:18:51 wisi systemd-timesyncd[29258]: Koha e sistemit është ndërruar. Po sinkronizohet nën të re.
Aug 25 21:18:51 wisi systemd[1187]: Koha është ndërruar
Aug 25 21:18:51 wisi systemd[1]: Koha është ndërruar
Aug 25 21:18:51 wisi systemd[1187]: Koha është ndërruar
këtu
# ps afx | grep "[1]187"
1187 ? Ss 0:02 /lib/systemd/systemd --user
Në këtë moment, duhej të kërkoja arsyen, por mendja, pas 18 vjetësh administrimi, ka krijuar statistikën e gabimeve «të kohës» dhe nga zakoni akoma e fajëson sinkronizimin.
E çaktivizojmë atë plotësisht.
# 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
dhe në log
Aug 25 21:25:40 wisi systemd[1]: Koha është ndërruar
Aug 25 21:25:40 wisi systemd[1187]: Koha është ndërruar
Aug 25 21:29:30 wisi systemd[1]: Koha është ndërruar
Aug 25 21:29:30 wisi systemd[1187]: Koha është ndërruar
Resyncing ka humbur dhe logët e tjera janë krejtësisht të pastra.
Kontrollojmë daljet tcpdump në portin 123 për të gjitha ndërfaqet. Nuk ka kërkesa, por koha vazhdon të «ikë».
Gabimi i dytë. Shpejta
Derisa mbetet një orë deri në fund të javës së punës, nuk dua të iki për fundjavë me një detyrë të parregullt të mbetur (mos u shqetësoni për kohën në kod, artikulli u shkrua në ditët në vijim).
Dhe këtu përsëri, në vend që të kërkoja shkakun, fillova të përpiqesha të shpikja një shpjegim për rezultatin. Po e quaj "të shpik" sepse, pavarësisht se sa logjikë mund të kenë shpjegimet për rezultatin, ky është një qasje e gabuar për zgjidhjen e problemeve.
Ky server është për transmetim dhe konverton rrjedhën DVB-S2 në IP. Në rrjedhën DVB-S ka marka kohe, prandaj marrësit, shumëpalesat, skremblerët dhe televizorët shpesh i përdorin ato për të sinkronizuar orët sistemike. Driverët e kartave DVB-S janë të inkorporuar në bërthamë, kështu që mënyra më e shpejtë për të garantuar heqjen e rrjedhës DVB-S2 është të çplugosni kabllot që vijnë nga "të enët". Fatmirësisht, serveri është përmur, kështu që kjo është ajo që do të bëhet.
Sigurisht, nëse në log do të kishte atë që duhet të ishte, kjo nuk do të ndodhte, por për këtë, përsëri, në fund të artikullit.
E tani që kemi hequr të gjitha sinjalet satelitore, heqim edhe ato tokësore — duke çplugosur të gjitha kabllot e rrjetit. Serveri bëhet i ndarë nga bota e jashtme dhe punon plotësisht autonom, por orët sistemike ende nxitonin.
Java e punës ka mbaruar, dhe vetë çështja e datës/kohës në të nuk është kritike, prandaj mund të shkojmë thjesht në shtëpi, por këtu bëj një gabim të ri.
Gabimi i tretë. Këshilltarët
Kurrë! Kurrë mos bëni pyetje në forume dhe në site të zakonshme (si stackoverflow), nëse përgjigja kërkon më shumë se sa studimi i rezultateve të faqes së parë në Google dhe leximin e një faqe man-it.
Do t'ju kthejnë përsëri në google, për të lexuar po atë man dhe do t'ju shpjegojnë në mënyrë popullore rregullat e forumit/saitit, por nuk do t'ju japin përgjigje.
Këtu ka faktorë objektivë:
- askush përveç teje nuk mund ta dijë problemin ashtu siç duhet;
- askush nuk mund të kryejë teste në kushte të ngjashme me tuajat
si dhe faktorë subjektivë:
- mund të mos jepni të gjitha inputet për zgjidhjen e problemit, sepse keni shpikur një drejtim "të duhur" dhe e shpjegoni qesen e pyetjes duke u fokusuar në të;
- nënkolonel (moderator, anëtar i vjetër, admin) gjithmonë ka të drejtë, nëse nënkoloneli nuk ka të drejtë... mirë, e dini ...
Nëse në komentet përgjigjëse keni mbetur brenda fjalorit të sjellshëm, atëherë do të thotë që keni nerva të forta.
Zgjidhja
Nuk ka nevojë të ndahen detyrat në të thjeshta dhe të vështira.
Ndalojmë së mbështeturi në përvojën tonë, statistikat, këshilltarët dhe fillojmë të mos "shpjegojmë" rezultatin përfundimtar, por të kërkojmë shkakun në mënyrë të njëpasnjëshme.
Nëse dikush vendos kohën, atëherë duhet të ndodhë një thirrje përkatëse sistemike.
Ashtu siç është dokumentuar në softuer, dokumentet më të mira janë burimet, ashtu edhe në administrimin e sistemeve, ndihmësi më i mirë është auditi, në rastin tonë. auditd.
Një çast dyshimiUnë kalova nëpër manuale, por nuk isha plotësisht i sigurt që koha në Linux mund të vendoset vetëm clock_settime dhe settimeofday, prandaj për testin e parë zgjodha të gjitha thirrjet "e përshtatshme":
# 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
dhe hodha poshtë s390_runtime_instr, stime, timerfd_create, të cilat auditctl nuk i pranoi, fillimisht e nisa auditin në formën:
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 utimesPas sigurisë që në vendet që më interesonin në loge nuk kishte të tjera syscalls përveç këtyre dyve, vazhdova të përdor vetëm ato.
Nisni auditin e thirrjeve sistemike clock_settime dhe settimeofday dhe provojmë të ndryshojmë datën:
# auditctl -a exit,always -S clock_settime -S settimeofday && date -s "2019-08-22 12:10:00" && sleep 5 && auditctl -D
Një vonesë pesë sekondëshe është e shtuar, që paraziti ynë të sigurohet që të korrigjojë kohën.
Shikojmë raportin:
# 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
Këtu shohim datën tonë date dhe një gjë që nuk e dimë chkcache_proces. Ai u shfaq në raportin e mësipërm, sepse aureport renditi daljen sipas datës gjatë transformimit nga forma binare, dhe ngjarja ndodhi në kohën që e vendosëm ne. date -s "2019-08-22 12:10:00".
Kush e krijoi atë?
# 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 — paraziti ynë u zbulua. Pavarësisht nga sjellja e tij "keqdashëse", nuk mund të anulojmë sistemin e aksesit të kushteve, por gjithsesi do të doja të dija, oscam, WTF?
Përgjigja u gjet shpejt në :
#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");
}
Sa bukur duken këtu komentuar rreshti warning’a…
Burimi: habr.com
