Kjo detyrë e parëndësishme u ngrit një pasdite të premte dhe duhej të kishte marrë 2-3 minuta kohë. Në përgjithësi, si gjithmonë.
Një koleg më kërkoi të rregulloja skenarin në serverin e tij. E bëra, ia dhashë dhe pa dashje rashë: "Koha është 5 minuta shpejt." Lëreni serverin të trajtojë vetë sinkronizimin. Kaloi gjysmë ore, një orë, dhe ai ende fryhej dhe mallkonte në heshtje.
“Budallaqe! — Mendova, duke kaluar në konsolën e serverit — në rregull, do të bëj një pushim edhe për disa minuta.
Le të shohim ntp, rdate, sdwdate jo i instaluar kohore i paaftë dhe nuk funksionon.
# 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ë vërej menjëherë se koha e harduerit është e saktë: do të jetë më e lehtë për të lundruar më tej.
Këtu filloi seria e gabimeve.
Gabimi i parë. Vetëbesim
Kliko-kliko...
# 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
Всё отлично, время синхронизировалось, системное совпадает с аппаратным. «Забирай», — обронил я и вернулся к своим делам.
“Merr çfarë? - u indinjua kolegu. "Është e njëjta kohë!"
Sa më shumë që të zgjidhni problemet tipike, aq më shumë të menduarit bëhet i turbullt dhe nuk mendoni më se situata e njëqindtë apo e njëmijtë 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
Ora e sistemit është përsëri e gabuar.
Le ta provojme perseri:
# 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
Le ta 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
Dhe si kjo:
# 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 është caktuar për një pjesë të sekondës dhe menjëherë fillon të "ngut" përsëri.
Në të njëjtën kohë, në regjistrat, në momentin e një ndryshimi të tillë manual, shohim vetëm raporte të sistemit se koha ka ndryshuar, përkatësisht në drejtimin e duhur/të gabuar dhe herë pas here. Risinkronizimi nga 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
këtu
# ps afx | grep "[1]187"
1187 ? Ss 0:02 /lib/systemd/systemd --user
Në këtë pikë, tashmë ishte e nevojshme të kërkohej arsyeja, por gjatë 18 viteve të administrimit, truri ka grumbulluar statistika për gabimet "kohore" dhe, nga zakoni, fajëson përsëri sinkronizimin.
Le ta fikim 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ë regjistrat
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
Risinkronizimi u zhduk dhe përndryshe trungjet janë të pacenuara.
Kontrollimi i përfundimeve tcpdump në portin 123 në të gjitha ndërfaqet. Nuk ka kërkesa, por koha ende po ikën.
Gabim dy. Nxitoni
Ka mbetur edhe nje ore deri ne fund te javes se punes dhe nuk dua te iki ne fundjave me nje problem te pazgjidhur (mos i kushtoni rendesi kohes ne kod, artikulli eshte shkruar ne ditet ne vazhdim ).
Dhe këtu përsëri, në vend që të kërkoja arsyen, fillova të përpiqem të dal me një shpjegim për rezultatin. Them “shpik” sepse sado logjik të jetë shpjegimi për rezultatin, është një qasje e gabuar për zgjidhjen e problemit.
Ky server është një server streaming dhe konverton transmetimin DVB-S2 në IP. Transmetimi DVB-S përmban vula kohore, kështu që marrësit, multipleksuesit, gërshetat dhe televizorët shpesh i përdorin ato për të sinkronizuar orën e sistemit. Drejtuesit e bordit DVB-S janë të integruar në kernel, kështu që mënyra më e shpejtë për të siguruar që rryma DVB-S2 të hiqet është shkëputja e kabllove që vijnë nga "pllakat". Për fat të mirë, serveri është pas murit, kështu qoftë.
Sigurisht, nëse regjistrat do të kishin përmbajtur atë që duhej të kishte, kjo nuk do të kishte ndodhur, por më shumë për këtë, përsëri, në fund të artikullit.
Epo, meqenëse tashmë i kemi hequr të gjitha sinjalet satelitore, do të heqim edhe ato tokësore - në të njëjtën kohë ne tërheqim të gjitha kabllot e rrjetit. Serveri shkëputet nga bota e jashtme dhe funksionon plotësisht në mënyrë autonome, por ora e sistemit është ende me nxitim.
Java e punës ka mbaruar dhe vetë çështja e datës/orarit nuk është kritike, kështu që thjesht mund të shkoni në shtëpi, por këtu bëj një gabim të ri.
Gabim tre. këshilltarët
Kurrë! Asnjëherë mos bëni pyetje në forume dhe faqet e përgjithshme të specializuara (a la stackoverflow) nëse përgjigja për të kërkon më shumë sesa studimi i faqes së parë të Google dhe leximi i një faqeje njeriu.
Ata do t'ju kthejnë në Google, do të lexojnë të njëjtin njeri dhe do t'ju shpjegojnë në mënyrë popullore rregullat e forumit/faqes, por nuk do t'ju japin përgjigje.
Këtu janë disa faktorë objektivë:
- askush përveç jush nuk mund ta dijë problemin gjithashtu;
- askush nuk mund të kryejë teste në të njëjtat kushte si tuajat
dhe subjektive:
- mund të mos jepni të gjithë kontributin për zgjidhjen e problemit, sepse tashmë keni dalë me drejtimin "e duhur" dhe po parashtroni thelbin e çështjes duke u fokusuar në të;
- Përgjegjësi (moderatori, administratori i vjetër, administratori) ka gjithmonë të drejtë, nëse kryepunëtori e ka gabim... mirë, e dini...
Nëse, kur u përgjigjeni komenteve, keni mbetur brenda kufijve të fjalorit të censuruar, atëherë keni nerva të fortë.
vendim
Nuk ka nevojë të ndani detyrat në të thjeshta dhe komplekse.
Ne 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ë vazhdimisht arsyen.
Meqenëse dikush cakton kohën, duhet të ndodhë thirrja përkatëse e sistemit.
Ashtu si në dokumentacionin e softuerit dokumentet më të mira janë burimet, ashtu edhe në administrimin e sistemit asistenti më i mirë është auditimi, në rastin tonë audituar.
Një moment dyshimiKam kaluar nëpër mana, por nuk isha plotësisht i sigurt se koha në Linux mund të vendoset vetëm koha e vendosjes së orës и ora e caktuar e ditës, kështu që për testin e parë zgjodha të gjitha thirrjet "të 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 duke hedhur poshtë s390_runtime_instr, stime, timerfd_create, e cila auditctl nuk e njohu atë, fillimisht filloi një auditim 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 utimesPasi të sigurohem që nuk ka regjistra të tjerë në vendndodhjet e regjistrave që më interesojnë sycalls Përveç këtyre të dyjave, unë i përdora vetëm ato më tej.
Kryerja e një auditimi të thirrjeve të sistemit koha e vendosjes së orës и ora e caktuar e ditës dhe përpiquni të ndryshoni datën:
# auditctl -a exit,always -S clock_settime -S settimeofday && date -s "2019-08-22 12:10:00" && sleep 5 && auditctl -D
Shtohet një vonesë prej pesë sekondash në mënyrë që "paraziti" ynë të garantohet të korrigjojë kohën.
Le të shohim 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 tonën data dhe i panjohur për ne chkcache_proceset. Përfundoi në raportin e mësipërm sepse aureport e renditi daljen sipas datës kur konvertohej nga binar dhe ngjarja ndodhi në kohën që ne caktuam data -s "2019-08-22 12:10:00".
Kush e lindi?
# 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 - është gjetur paraziti ynë. Megjithë sjelljen e tij "me qëllim të keq", është e pamundur të refuzosh sistemin e aksesit të kushtëzuar, por prapë do të doja ta dija oscam, WTF?
Përgjigja gjendet 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 duket këtu komentoi linjë paralajmërim...
Burimi: www.habr.com