Hierdie onbenullige taak het een Vrydagmiddag ontstaan en moes 2-3 minute se tyd geneem het. Oor die algemeen, soos altyd.
'n Kollega het my gevra om die skrif op sy bediener reg te maak. Ek het dit gedoen, dit vir hom gegee en per ongeluk laat val: "Tyd is 5 minute vinnig." Laat die bediener die sinchronisasie self hanteer. 'n Halfuur, 'n uur het verbygegaan, en hy het steeds geblaas en stil gevloek.
"Onnosel! — Ek het gedink terwyl ek na die bedienerkonsole oorgeskakel het — goed, ek neem 'n breek vir nog 'n paar minute.
Kom ons kyk ntp, rdate, sdwdate nie geïnstalleer nie tydsynk gedeaktiveer en nie loop nie.
# 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
Hier sal ek dadelik opmerk dat die hardeware tyd korrek is: dit sal makliker wees om verder te navigeer.
Dit is waar die reeks foute begin het.
Die eerste fout. Selfvertroue
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, die tyd is gesinchroniseer, die stelseltyd pas by die hardeware een. "Vat dit," het ek gesê en teruggekeer na my besigheid.
“Vat wat? - die kollega was verontwaardig. “Dis dieselfde tyd!”
Hoe meer jy tipiese probleme oplos, hoe meer raak jou denke flikker en dink jy nie meer dat die honderdste of duisendste situasie anders sal wees nie, maar nie hierdie keer nie.
# 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
Die stelseltyd is weer verkeerd.
Kom ons probeer weer:
# 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
Kom ons doen dit anders:
# 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 so:
# 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
Die tyd is ingestel vir 'n breukdeel van 'n sekonde, en begin dadelik weer "haas".
Terselfdertyd, in die logs, ten tyde van so 'n handmatige verandering, sien ons slegs stelselverslae dat die tyd onderskeidelik in die regte/verkeerde rigting en soms verander het Hersinkroniseer van 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
hier
# ps afx | grep "[1]187"
1187 ? Ss 0:02 /lib/systemd/systemd --user
Op hierdie stadium was dit reeds nodig om die rede te soek, maar oor 18 jaar van administrasie het die brein statistieke oor "tyd"-foute opgehoop en, uit gewoonte, weer sinchronisasie blameer.
Kom ons skakel dit heeltemal af.
# 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 in die 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
Hersinkroniseer verdwyn en andersins is die stompe ongerept.
Kontroleer die gevolgtrekkings tcpdump op poort 123 op alle koppelvlakke. Daar is geen versoeke nie, maar die tyd hardloop nog weg.
Fout twee. Stormloop
Daar is 'n uur oor tot die einde van die werksweek, en ek wil nie vir die naweek vertrek met 'n onbenullige onopgeloste probleem nie (moenie let op die tyd in die kode nie, die artikel is in die volgende dae geskryf ).
En hier het ek weer, in plaas daarvan om die rede te soek, begin om met 'n verduideliking vir die resultaat vorendag te probeer kom. Ek sê "bedink" want dit maak nie saak hoe logies die verduideliking vir die resultaat is nie, dit is 'n gebrekkige benadering om die probleem op te los.
Hierdie bediener is 'n stroombediener en skakel die DVB-S2-stroom om na IP. Die DVB-S-stroom bevat tydstempels, so ontvangers, multipleksers, scramblers en televisies gebruik dit dikwels om die stelselklok te sinchroniseer. DVB-S-bordbestuurders is in die kern ingebou, dus die vinnigste manier om te verseker dat die DVB-S2-stroom verwyder word, is om die kabels wat van die "plate" af kom, te ontkoppel. Gelukkig is die bediener agter die muur, so moet dit so wees.
Natuurlik, as die logboeke bevat het wat daar moes wees, sou dit nie gebeur het nie, maar meer daaroor, weer, aan die einde van die artikel.
Wel, aangesien ons reeds alle satellietseine verwyder het, sal ons ook terrestriële seine verwyder - terselfdertyd trek ons al die netwerkkabels uit. Die bediener raak afgesny van die buitewêreld en werk heeltemal outonoom, maar die stelselklok is steeds haastig.
Die werksweek is verby, en die datum/tyd kwessie self is nie krities nie, so jy kan maar huis toe gaan, maar hier maak ek 'n nuwe fout.
Fout drie. Adviseurs
Nooit! Moet nooit vrae op forums en algemene gespesialiseerde (a la stackoverflow) werwe vra as die antwoord daarop meer verg as om die eerste bladsy van Google te bestudeer en een manbladsy te lees nie.
Hulle sal jou terugstuur na Google, dieselfde man lees en die reëls van die forum/werf algemeen verduidelik, maar sal nie vir jou 'n antwoord gee nie.
Hier is 'n paar objektiewe faktore:
- niemand behalwe jy kan die probleem ook ken nie;
- niemand kan toetse onder dieselfde omstandighede as joune doen nie
en subjektief:
- jy mag dalk nie al die insette gee om die probleem op te los nie, want jy het reeds met die “regte” rigting vorendag gekom en die kern van die saak voorlê deur daarop te fokus;
- die voorman (moderator, oud-timer, admin) is altyd reg, as die voorman verkeerd is... wel, jy weet...
As jy, wanneer jy op kommentaar geantwoord het, binne die perke van gesensureerde woordeskat gebly het, dan het jy sterk senuwees.
besluit
Dit is nie nodig om take in eenvoudig en kompleks te verdeel nie.
Ons hou op om op ons ervaring, statistieke, raadgewers staat te maak en begin om nie die eindresultaat te "verduidelik" nie, maar om konsekwent na die rede te soek.
Aangesien iemand die tyd stel, moet die ooreenstemmende stelseloproep plaasvind.
Net soos in sagtewaredokumentasie die beste dokumente die bronne is, so in stelseladministrasie is die beste assistent oudit, in ons geval geoudit.
'n Oomblik van twyfelEk het deur die mana gegaan, maar was nie heeltemal seker dat die tyd in Linux net gestel kan word nie klok_settyd и stel tyd van die dag, so vir die eerste toets het ek al die "geskikte" oproepe gekies:
# 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 weggooi s390_runtime_instr, stime, timerfd_create, watter ouditktl het dit nie herken nie, het aanvanklik 'n oudit van stapel gestuur in die vorm:
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 utimesNadat ek seker gemaak het dat daar geen ander logs in die log-liggings is nie, stel ek belang in syskale Behalwe hierdie twee het ek net hulle verder gebruik.
Begin 'n stelseloproepoudit klok_settyd и stel tyd van die dag en probeer om die datum te verander:
# auditctl -a exit,always -S clock_settime -S settimeofday && date -s "2019-08-22 12:10:00" && sleep 5 && auditctl -D
'n Vertraging van vyf sekondes word bygevoeg sodat ons "parasiet" gewaarborg is om die tyd reg te stel.
Kom ons kyk na die verslag:
# 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
Hier sien ons ons datum en vir ons onbekend chkcache_prosesse. Dit het in die verslag hierbo beland omdat aureport die uitset volgens datum gesorteer het wanneer dit van binêre omgeskakel is, en die gebeurtenis het plaasgevind op die tyd wat ons gestel het datum -s "2019-08-22 12:10:00".
Wie het aan hom geboorte gegee?
# 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 - ons parasiet is gevind. Ten spyte van sy “kwaadwillige” gedrag, is dit onmoontlik om die voorwaardelike toegangstelsel te weier, maar ek wil steeds weet oscam, WTF?
Die antwoord word vinnig gevind in :
#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");
}
Hoe oulik lyk dit hier kommentaar gelewer het lyn waarskuwing...
Bron: will.com