Bu əhəmiyyətsiz iş bir cümə günü günortadan sonra ortaya çıxdı və 2-3 dəqiqə vaxt aparmalı idi. Ümumiyyətlə, həmişəki kimi.
Bir həmkarım məndən onun serverində skripti düzəltməyi xahiş etdi. Mən bunu etdim, ona uzatdım və təsadüfən yerə düşdüm: "Vaxt 5 dəqiqə tezdir." Sinxronizasiyanı serverin özü idarə etsin. Yarım saat, bir saat keçdi və o, yenə də şişirdi və sakitcə söydü.
“Axmaq! — Fikirləşdim ki, server konsoluna keçərək — tamam, daha bir neçə dəqiqə fasilə verəcəm.
Görək ntp, tarix, sdwdate quraşdırılmayıb timesycd əlil və işləmir.
# 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
Burada dərhal qeyd edəcəm ki, aparat vaxtının düzgün olduğunu: daha da naviqasiya etmək daha asan olacaq.
Burada səhvlər silsiləsi başladı.
İlk səhv. Özünə inam
Klik-klik...
# 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
Hər şey qaydasındadır, vaxt sinxronlaşdırılıb, sistem vaxtı hardware ilə uyğun gəlir. “Al bunu” dedim və işimə qayıtdım.
“Nə al? - həmkarı qəzəbləndi. "Eyni vaxtdır!"
Tipik problemləri həll etdikcə, düşüncələriniz bir o qədər kövrəlir və artıq yüzüncü və ya mininci vəziyyətin fərqli olacağını düşünmürsünüz, amma bu dəfə yox.
# 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
Sistem vaxtı yenə səhvdir.
Yenidən cəhd edək:
# 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
Gəlin bunu fərqli edək:
# 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
Və bu kimi:
# 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
Vaxt bir saniyəyə təyin edilir və dərhal yenidən "tələsməyə" başlayır.
Eyni zamanda, qeydlərdə, belə bir əl dəyişdirmə zamanı, yalnız sistem hesabatlarını görürük ki, zaman müvafiq olaraq düzgün/səhv istiqamətdə və bəzən dəyişib. Yenidən sinxronlaşdırılır systemd-timesyncd-dən.
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
burada
# ps afx | grep "[1]187"
1187 ? Ss 0:02 /lib/systemd/systemd --user
Bu nöqtədə artıq səbəbi axtarmaq lazım idi, lakin 18 il ərzində beyin "vaxt" səhvləri ilə bağlı statistik məlumatlar topladı və vərdişdən kənar olaraq yenidən sinxronizasiyanı günahlandırdı.
Gəlin onu tamamilə söndürək.
# 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
və loglarda
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
Yenidən sinxronlaşdırılır yoxa çıxdı və əks halda loglar təmizdir.
Nəticələrin yoxlanılması tcpdump bütün interfeyslərdə 123 portunda. Heç bir müraciət yoxdur, amma vaxt hələ də axır.
Səhv ikinci. Tələsmək
İş həftəsinin bitməsinə bir saat qalıb və mən cüzi həll olunmamış problemlə həftəsonuna çıxmaq istəmirəm (koddakı vaxta fikir verməyin, məqalə sonrakı günlərdə yazılıb. ).
Və burada yenə səbəb axtarmaq əvəzinə nəticənin izahını tapmağa çalışmağa başladım. Mən “icad edirəm” deyirəm, çünki nəticənin izahı nə qədər məntiqli olsa da, problemin həllinə qüsurlu yanaşmadır.
Bu server axın serveridir və DVB-S2 axınını IP-yə çevirir. DVB-S axınında vaxt ştampları var, ona görə də qəbuledicilər, multipleksorlar, skrambller və televizorlar sistem saatını sinxronlaşdırmaq üçün onlardan tez-tez istifadə edirlər. DVB-S board drayverləri nüvəyə quraşdırılmışdır, buna görə də DVB-S2 axınının silinməsini təmin etməyin ən sürətli yolu “plitələrdən” gələn kabelləri ayırmaqdır. Xoşbəxtlikdən, server divarın arxasındadır, belə də olsun.
Əlbəttə ki, jurnallarda orada olması lazım olan şey olsaydı, bu baş verməzdi, amma daha çox məqalənin sonunda.
Yaxşı, biz artıq bütün peyk siqnallarını sildiyimiz üçün yerüstü siqnalları da çıxaracağıq - eyni zamanda bütün şəbəkə kabellərini çıxarırıq. Server xarici dünya ilə əlaqəsi kəsilir və tamamilə avtonom işləyir, lakin sistem saatı hələ də tələsir.
İş həftəsi bitdi və tarix/saat məsələsinin özü kritik deyil, ona görə də sadəcə evə gedə bilərsiniz, amma burada yeni səhv edirəm.
Səhv üçüncü. Məsləhətçilər
Heç vaxt! Əgər bunun cavabı Google-un ilk səhifəsini öyrənməkdən və bir insan səhifəsini oxumaqdan daha çox tələb edirsə, heç vaxt forumlarda və ümumi ixtisaslaşmış (a la stackoverflow) saytlarda sual verməyin.
Sizi yenidən Google-a göndərəcəklər, eyni adamı oxuyacaqlar və forumun/saytın qaydalarını məşhur şəkildə izah edəcəklər, amma sizə cavab verməyəcəklər.
Budur bəzi obyektiv amillər:
- problemi sizdən başqa heç kim bilə bilməz;
- heç kim sizinlə eyni şərtlər altında testlər keçirə bilməz
və subyektiv:
- problemin həlli üçün bütün məlumatları verməyə bilərsən, çünki siz artıq “düzgün” istiqamət tapmısınız və ona diqqət yetirərək məsələnin mahiyyətini təqdim edirsiniz;
- usta (moderator, köhnə, admin) həmişə haqlıdır, usta səhvdirsə... yaxşı, bilirsən...
Şərhlərə cavab verərkən senzuraya məruz qalmış lüğətin hüdudlarında qaldınızsa, deməli əsəbləriniz güclüdür.
qərar
Tapşırıqları sadə və mürəkkəbə bölməyə ehtiyac yoxdur.
Biz öz təcrübəmizə, statistikamıza, məsləhətçilərimizə güvənməyi dayandırırıq və son nəticəni “izah etməyə” deyil, ardıcıl olaraq səbəbi axtarmağa başlayırıq.
Kimsə vaxtı təyin etdiyi üçün müvafiq sistem çağırışı baş verməlidir.
Proqram sənədlərində ən yaxşı sənədlər mənbələr olduğu kimi, sistem idarəçiliyində də ən yaxşı köməkçi auditdir, bizim vəziyyətimizdə yoxlanılır.
Bir anlıq şübhəMən manadan keçdim, lakin Linux-da vaxtın yalnız təyin oluna biləcəyinə tam əmin deyildim saat_qurulma vaxtı и günün təyini, buna görə də ilk sınaq üçün bütün "uyğun" zəngləri seçdim:
# 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
və atma s390_runtime_instr, stime, timerfd_create, hansı auditctl tanımadı, əvvəlcə formada yoxlamaya başladı:
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 utimesMəni maraqlandıran qeyd yerlərində başqa qeydlərin olmadığına əmin olduqdan sonra qüsurlar Bu ikisindən başqa, yalnız onlardan istifadə etdim.
Sistem çağırışı auditinin həyata keçirilməsi saat_qurulma vaxtı и günün təyini və tarixi dəyişdirməyə çalışın:
# auditctl -a exit,always -S clock_settime -S settimeofday && date -s "2019-08-22 12:10:00" && sleep 5 && auditctl -D
Beş saniyəlik gecikmə əlavə olunur ki, "parazitimiz" vaxtı düzəltməyə zəmanət verilir.
Gəlin hesabata baxaq:
# 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
Burada özümüzü görürük tarix və bizə məlum deyil chkcache_processes. Bu, yuxarıdakı hesabatda sona çatdı, çünki aureport ikili sistemdən çevirərkən çıxışı tarixə görə çeşidlədi və hadisə bizim təyin etdiyimiz vaxtda baş verdi. tarix -s "2019-08-22 12:10:00".
Onu kim dünyaya gətirdi?
# 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 - parazitimiz tapıldı. "Zərərli" davranışına baxmayaraq, şərti giriş sistemindən imtina etmək mümkün deyil, amma yenə də bilmək istərdim oscam, WTF?
Cavab tez tapılır :
#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");
}
Bura necə şirin görünür şərh etdi xətt xəbərdarlıq...
Mənbə: www.habr.com