Dizze triviale taak ûntstie op in freedtemiddei en soe 2-3 minuten tiid moatte nimme. Yn it algemien, lykas altyd.
In kollega frege my om it skript op syn server te reparearjen. Ik die it, joech it oan him en liet ûnbedoeld falle: "De tiid is 5 minuten fluch." Lit de tsjinner de syngronisaasje sels behannelje. In healoere, in oere gie foarby, en hy pûste noch stil en flokte.
"Stom! - Ik tocht, oerstap nei de serverkonsole - okee, ik nim noch in pear minuten in skoft.
Litte wy sjen ntp, rdate, sdwdate net ynstallearre tiidsyncd útskeakele en net rinne.
# 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
Hjir sil ik fuortendaliks opmerke dat de hardwaretiid korrekt is: it sil makliker wêze om fierder te navigearjen.
Dit is wêr't de rige flaters begon.
De earste flater. Selsfertrouwen
Klik-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
Alles is goed, de tiid is syngronisearre, de systeemtiid komt oerien mei de hardware. "Nim it," sei ik en gie werom nei myn bedriuw.
"Nim wat? - de kollega wie fergriemd. "It is deselde tiid!"
Hoe mear jo typyske problemen oplosse, hoe mear jo tinken blinker wurdt en jo tinke net mear dat de hûndertste of tûzenste situaasje oars sil wêze, mar dizze kear net.
# 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
It systeem tiid is ferkeard wer.
Noch in kear besykje:
# 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
Litte wy it oars dwaan:
# 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
En sa:
# 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
De tiid is ynsteld foar in split sekonde, en fuortendaliks begjint te "rush" wer.
Tagelyk sjogge wy yn 'e logs, op' e tiid fan sa'n hânmjittige feroaring, allinich systeemrapporten dat de tiid respektivelik yn 'e goede/ferkearde rjochting en soms feroare is Opnij syngronisearje fan 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
hjir
# ps afx | grep "[1]187"
1187 ? Ss 0:02 /lib/systemd/systemd --user
Op dit punt wie it al nedich om de reden te sykjen, mar oer 18 jierren fan administraasje hat it harsens statistiken sammele oer "tiid" flaters en, út gewoante, wer skuld syngronisaasje.
Litte wy it folslein útsette.
# 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
en yn de logs
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
Opnij syngronisearje ferdwûn en oars binne de logs ûnrêstich.
Kontrolearje de konklúzjes tcpdump op haven 123 op alle ynterfaces. Der binne gjin oanfragen, mar de tiid rint noch fuort.
Flater twa. Rush
D'r is in oere oer oant it ein fan 'e wurkwike, en ik wol net foar it wykein fuortgean mei in triviale ûnoplost probleem (let net op 'e tiid yn' e koade, it artikel is skreaun yn 'e folgjende dagen ).
En hjir wer, yn stee fan it sykjen nei de reden, begûn ik te besykjen om te kommen mei in ferklearring foar it resultaat. Ik sis "útfine", om't hoe logysk de ferklearring foar it resultaat ek wêze kin, it is in gebrekkige oanpak om it probleem op te lossen.
Dizze tsjinner is in streaming-tsjinner en konvertearret de DVB-S2-stream yn IP. De DVB-S-stream befettet tiidstempels, sadat ûntfangers, multiplexers, scramblers en televyzjes se faak brûke om de systeemklok te syngronisearjen. DVB-S board-bestjoerders binne yn 'e kearn ynboud, dus de fluchste manier om te soargjen dat de DVB-S2-stream wurdt fuortsmiten is om de kabels fan' e "platen" te ferbrekken. Gelokkich is de server efter de muorre, sa sil it wêze.
Fansels, as der yn de logboeken stien hie wat der stean moast, soe dat net bard wêze, mar dêroer wer mear oan it ein fan it artikel.
No, om't wy alle satellytsinjalen al hawwe fuortsmiten, sille wy ek ierdske fuortsmite - tagelyk lûke wy alle netwurkkabels út. De tsjinner wurdt ôfsnien fan 'e bûtenwrâld en wurket folslein autonoom, mar de systeemklok is noch altyd haast.
De wurkwike is foarby, en de datum/tiid kwestje sels is net kritysk, dus jo kinne gewoan nei hûs, mar hjir meitsje ik in nije flater.
Flater trije. Adviseurs
Nea! Nea freegje fragen op foarums en algemiene spesjalisearre (a la stackoverflow) sites as it antwurd op it fereasket mear as it bestudearjen fan de earste side fan Google en it lêzen fan ien man side.
Se stjoere jo werom nei Google, lêze deselde man en ferklearje populêr de regels fan it foarum/side, mar jouwe jo gjin antwurd.
Hjir binne wat objektive faktoaren:
- gjinien útsein jo kinne it probleem ek witte;
- gjinien kin tests útfiere ûnder deselde betingsten as jo
en subjektyf:
- jo meie net alle ynput jaan foar it oplossen fan it probleem, om't jo al mei de "rjochte" rjochting binne kommen en de essinsje fan 'e kwestje presintearje dy't jo derop rjochtsje;
- de foarman (moderator, oldtimer, admin) hat altyd gelyk, as de foarman ferkeard is... no, do witst...
As jo, by it beäntwurdzjen fan opmerkingen, binnen de grinzen fan sensurearre wurdskat bleaunen, dan hawwe jo sterke senuwen.
beslút
It is net nedich om taken te ferdielen yn ienfâldige en komplekse.
Wy stopje mei te fertrouwen op ús ûnderfining, statistiken, adviseurs en begjinne it einresultaat net te "ferklearjen", mar om konsekwint te sykjen nei de reden.
Om't immen de tiid ynstelt, moat de korrespondearjende systeemoprop foarkomme.
Krekt sa't yn softwaredokumintaasje de bêste dokuminten de boarnen binne, sa is yn systeemadministraasje de bêste assistint audit, yn ús gefal auditd.
In momint fan twifelIk gie troch de mana, mar wie net hielendal wis dat de tiid yn Linux kin allinnich wurde ynsteld klok_settiid и settimeofday, dus foar de earste test keas ik alle "passende" oproppen:
# 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
en wegwerpen s390_runtime_instr, stime, timerfd_create, hokker auditctl erkende it net, lansearre earst in kontrôle yn 'e foarm:
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 utimesNei't der wis fan is dat d'r gjin oare logs binne yn 'e loglokaasjes dy't ik bin ynteressearre yn syscalls Njonken dizze twa brûkte ik se allinich fierder.
It útfieren fan in systeemoprop audit klok_settiid и settimeofday en besykje de datum te feroarjen:
# auditctl -a exit,always -S clock_settime -S settimeofday && date -s "2019-08-22 12:10:00" && sleep 5 && auditctl -D
In fertraging fan fiif sekonden wurdt tafoege sadat ús "parasyt" garandearre is om de tiid te korrigearjen.
Litte wy nei it rapport sjen:
# 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
Hjir sjogge wy ús datum en ûnbekend foar ús chkcache_prosessen. It einige yn it rapport hjirboppe om't aureport de útfier sortearre op datum by it konvertearjen fan binêr, en it evenemint barde op it momint dat wy ynsteld hawwe datum -s "2019-08-22 12:10:00".
Wa hat him berne?
# 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 - ús parasyt is fûn. Nettsjinsteande syn "kwaadwillige" gedrach is it ûnmooglik om it systeem foar betingst tagong te wegerjen, mar ik wol it noch wol witte oscam, WTF?
It antwurd is gau te finen yn :
#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");
}
Wat liket it hjir kreas kommentearre út rigel warskôging...
Boarne: www.habr.com