Ĉi tiu bagatela tasko ekestis iun vendredon posttagmeze kaj devus esti preninta 2-3 minutojn da tempo. Ĝenerale, kiel ĉiam.
Kolego petis min ripari la skripton sur sia servilo. Mi faris ĝin, donis ĝin al li kaj preterintence faligis: "La tempo estas 5 minutojn rapida." Lasu la servilon prizorgi la sinkronigon mem. Pasis duonhoro, horo, kaj li ankoraŭ pufiĝis kaj trankvile malbenis.
“Stulta! — mi pensis, ŝanĝante al la servila konzolo — bone, mi faros paŭzon dum kelkaj pliaj minutoj.”
Ni vidu ntp, rdate, sdwdate ne instalita timesyncd malfunkciigita kaj ne funkcianta.
# 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
Ĉi tie mi tuj rimarkos, ke la aparatara tempo estas ĝusta: estos pli facile navigi plu.
Ĉi tie komenciĝis la serio de eraroj.
La unua eraro. Memfido
Klak-klako...
# 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
Ĉio estas bona, la tempo estas sinkronigita, la sistema tempo kongruas kun la aparataro. "Prenu ĝin," mi diris kaj revenis al mia komerco.
“Prenu kion? — indignis la kolego. "Estas la sama tempo!"
Ju pli vi solvas tipajn problemojn, des pli via pensado palpebrumas kaj vi ne plu pensas, ke la centa aŭ mila situacio estos malsama, sed ĉi-foje ne.
# 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
La sistema horo denove estas malĝusta.
Ni provu denove:
# 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
Ni faru ĝin alimaniere:
# 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
Kaj tiel:
# 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
La tempo estas fiksita por sekundo, kaj tuj komencas "rapidi" denove.
Samtempe, en la protokoloj, en la momento de tia mana ŝanĝo, ni vidas nur sistemajn raportojn, ke la tempo ŝanĝiĝis, respektive, en la ĝusta/malĝusta direkto kaj foje Resyncing de 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
tie
# ps afx | grep "[1]187"
1187 ? Ss 0:02 /lib/systemd/systemd --user
Je ĉi tiu punkto, jam estis necese serĉi la kialon, sed dum 18 jaroj de administrado, la cerbo amasigis statistikojn pri "tempaj" eraroj kaj, pro kutimo, denove kulpigas sinkronigon.
Ni tute malŝaltu ĝin.
# 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
kaj en la ŝtipoj
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
Resyncing malaperis kaj alie la ŝtipoj estas puraj.
Kontrolante la konkludojn tcpdump sur haveno 123 sur ĉiuj interfacoj. Ne estas petoj, sed la tempo ankoraŭ forkuras.
Eraro du. Rush
Restas unu horo ĝis la fino de la laborsemajno, kaj mi ne volas foriri por la semajnfino kun bagatela nesolvita problemo (ne atentu la tempon en la kodo, la artikolo estis skribita en la sekvaj tagoj. ).
Kaj ĉi tie denove, anstataŭ serĉi la kialon, mi komencis provi elpensi klarigon por la rezulto. Mi diras "inventi" ĉar kiom ajn logika la klarigo por la rezulto povas esti, ĝi estas misa aliro por solvi la problemon.
Ĉi tiu servilo estas fluanta servilo kaj konvertas la DVB-S2-rivereton al IP. La DVB-S-rivereto enhavas tempomarkojn, do riceviloj, multipleksiloj, miksiloj kaj televidiloj ofte uzas ilin por sinkronigi la sisteman horloĝon. DVB-S-tabulo-ŝoforoj estas konstruitaj en la kernon, do la plej rapida maniero certigi, ke la DVB-S2-rivereto estas forigita, estas malkonekti la kablojn venantajn de la "platoj". Feliĉe, la servilo estas malantaŭ la muro, do tiel estu.
Kompreneble, se la ŝtipoj enhavus tion, kio devus esti tie, tio ne estus okazinta, sed pli pri tio, denove, ĉe la fino de la artikolo.
Nu, ĉar ni jam forigis ĉiujn satelitajn signalojn, ni ankaŭ forigos surterajn - samtempe ni eltiras ĉiujn retajn kablojn. La servilo iĝas fortranĉita de la ekstera mondo kaj funkcias tute aŭtonomie, sed la sistema horloĝo ankoraŭ rapidas.
La laborsemajno finiĝis, kaj la dato/hora temo mem ne estas kritika, do vi povas simple iri hejmen, sed ĉi tie mi faras novan eraron.
Eraro tri. Konsilistoj
Neniam! Neniam faru demandojn en forumoj kaj ĝeneralaj specialigitaj (al la stackoverflow) retejoj se la respondo al ĝi postulas pli ol studi la unuan paĝon de Guglo kaj legi unu manpaĝon.
Ili resendos vin al Guglo, legos la saman homon kaj popole klarigos la regulojn de la forumo/retejo, sed ne donos al vi respondon.
Jen kelkaj objektivaj faktoroj:
- neniu krom vi povas scii ankaŭ la problemon;
- neniu povas fari testojn sub la samaj kondiĉoj kiel la viaj
kaj subjektiva:
- vi eble ne donas la tutan enigaĵon por solvi la problemon, ĉar vi jam elpensis la "ĝustan" direkton kaj prezentas la esencon de la afero koncentriĝante al ĝi;
- la skipestro (moderatoro, maljunulo, administranto) ĉiam pravas, se la skipestro eraras... nu, vi scias...
Se, respondante al komentoj, vi restis en la limoj de cenzurita vortprovizo, tiam vi havas fortajn nervojn.
decido
Ne necesas dividi taskojn en simplajn kaj kompleksajn.
Ni ĉesas fidi nian sperton, statistikojn, konsilistojn kaj komencas ne "klarigi" la finan rezulton, sed konstante serĉi la kialon.
Ĉar iu fiksas la horon, la responda sistemvoko devas okazi.
Same kiel en programardokumentado la plej bonaj dokumentoj estas la fontoj, tiel en sistema administrado la plej bona asistanto estas revizio, en nia kazo reviziita.
Momento de duboMi ekzamenis la manaon, sed ne estis tute certa, ke la tempo en Linukso nur povas esti agordita clock_settime и difino de tago, do por la unua testo mi elektis ĉiujn "taŭgajn" alvokojn:
# 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
kaj forĵetante s390_runtime_instr, stime, timerfd_create, kiu auditctl ne rekonis ĝin, komence lanĉis revizion en la formo:
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 utimesPost certigi, ke ne estas aliaj protokoloj en la protokoloj, pri kiuj mi interesiĝas syscalls Krom ĉi tiuj du, mi uzis nur ilin plu.
Efektivigo de sistema alvoko-revizio clock_settime и difino de tago kaj provu ŝanĝi la daton:
# auditctl -a exit,always -S clock_settime -S settimeofday && date -s "2019-08-22 12:10:00" && sleep 5 && auditctl -D
Kvin-sekunda prokrasto estas aldonita, por ke nia "parazito" garantiu korekti la tempon.
Ni rigardu la raporton:
# 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
Jen ni vidas nian dato kaj nekonata de ni chkcache_processes. Ĝi finiĝis en la supra raporto ĉar aureport ordigis la produktaĵon laŭ dato dum konvertado de duuma, kaj la evento okazis je la tempo, kiun ni fiksis. dato -s "2019-08-22 12:10:00".
Kiu naskis lin?
# 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 - nia parazito estas trovita. Malgraŭ ĝia "malica" konduto, estas neeble rifuzi la kondiĉan alirsistemon, sed mi ankoraŭ ŝatus scii oscam, WTF?
La respondo estas rapide trovita en :
#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");
}
Kiel bela ĝi aspektas ĉi tie komentis linio averto...
fonto: www.habr.com