Denne trivielle opgave opstod en fredag eftermiddag og skulle have taget 2-3 minutters tid. Generelt, som altid.
En kollega bad mig rette scriptet på hans server. Jeg gjorde det, rakte ham det og faldt uforvarende: "Tiden er 5 minutter hurtigt." Lad serveren selv klare synkroniseringen. Der gik en halv time, en time, og han pustede stadig og bandede stille.
"Dum! - Jeg tænkte, og skiftede til serverkonsollen - okay, jeg tager en pause i et par minutter mere."
Lad os se ntp, rdate, sdwdate ikke installeret tidssynkronisering deaktiveret og kører ikke.
# 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
Her vil jeg straks bemærke, at hardwaretiden er korrekt: det vil være lettere at navigere videre.
Det var her, rækken af fejl begyndte.
Den første fejl. Selvtillid
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
Alt er fint, tiden er synkroniseret, systemtiden matcher hardwaren. "Tag den," sagde jeg og vendte tilbage til min virksomhed.
"Tag hvad? - kollegaen var indigneret. "Det er samme tid!"
Jo mere du løser typiske problemer, jo mere blinker din tankegang, og du tror ikke længere, at hundrede eller tusinde situation vil være anderledes, men ikke denne gang.
# 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
Systemtiden er igen forkert.
Lad os prøve igen:
# 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
Lad os gøre det anderledes:
# 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
Og sådan her:
# 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
Tiden er sat til et splitsekund, og begynder straks at "rushe" igen.
Samtidig ser vi i loggene på tidspunktet for en sådan manuel ændring kun systemrapporter om, at tidspunktet er ændret henholdsvis i den rigtige/forkerte retning og lejlighedsvis Gensynkroniserer fra 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
her
# ps afx | grep "[1]187"
1187 ? Ss 0:02 /lib/systemd/systemd --user
På dette tidspunkt var det allerede nødvendigt at lede efter årsagen, men i løbet af 18 års administration har hjernen akkumuleret statistikker over "tids"-fejl og giver af vane igen skylden for synkronisering.
Lad os slå det helt fra.
# 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
og i loggene
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
Gensynkroniserer forsvundet, og ellers er træstammerne uberørte.
Kontrol af konklusionerne tcpdump på port 123 på alle grænseflader. Der er ingen forespørgsler, men tiden løber stadig væk.
Fejl to. Siv
Der er en time tilbage til slutningen af arbejdsugen, og jeg vil ikke tage afsted i weekenden med et trivielt uløst problem (vær ikke opmærksom på tidspunktet i koden, artiklen blev skrevet i de følgende dage ).
Og her begyndte jeg igen, i stedet for at lede efter årsagen, at forsøge at komme med en forklaring på resultatet. Jeg siger "opfind", fordi uanset hvor logisk forklaringen på resultatet måtte være, er det en mangelfuld tilgang til at løse problemet.
Denne server er en streamingserver og konverterer DVB-S2-strømmen til IP. DVB-S-strømmen indeholder tidsstempler, så modtagere, multipleksere, scramblere og fjernsyn bruger dem ofte til at synkronisere systemuret. DVB-S-kortdrivere er indbygget i kernen, så den hurtigste måde at sikre, at DVB-S2-strømmen er fjernet, er at afbryde kablerne, der kommer fra "pladerne". Heldigvis er serveren bag væggen, så det må være.
Hvis loggene havde indeholdt det, der skulle stå, ville dette selvfølgelig ikke være sket, men mere om det, igen, sidst i artiklen.
Nå, da vi allerede har fjernet alle satellitsignaler, fjerner vi også jordbaserede signaler - samtidig trækker vi alle netværkskablerne ud. Serveren bliver afskåret fra omverdenen og arbejder fuldstændig autonomt, men systemuret har stadig travlt.
Arbejdsugen er slut, og selve dato/klokkeslæt spørgsmålet er ikke kritisk, så du kan bare tage hjem, men her laver jeg en ny fejl.
Fejl tre. Rådgivere
Aldrig! Stil aldrig spørgsmål på fora og generelt specialiserede (a la stackoverflow) websteder, hvis svaret kræver mere end at studere den første side af Google og læse én man-side.
De vil sende dig tilbage til Google, læse den samme mand og populært forklare reglerne for forummet/siden, men vil ikke give dig et svar.
Her er nogle objektive faktorer:
- ingen undtagen du kan også kende problemet;
- ingen kan udføre tests under de samme betingelser som dine
og subjektivt:
- du giver måske ikke alle input til at løse problemet, fordi du allerede har fundet frem til den "rigtige" retning og præsenterer essensen af problemet med fokus på det;
- værkføreren (moderator, oldtimer, admin) har altid ret, hvis værkføreren tager fejl... ja, du ved...
Hvis du, når du besvarede kommentarer, forblev inden for grænserne af censureret ordforråd, så har du stærke nerver.
beslutning
Der er ingen grund til at opdele opgaver i enkle og komplekse.
Vi holder op med at stole på vores erfaring, statistikker, rådgivere og begynder ikke at "forklare" slutresultatet, men konsekvent at lede efter årsagen.
Da nogen indstiller tiden, skal det tilsvarende systemkald forekomme.
Ligesom i softwaredokumentation er de bedste dokumenter kilderne, så i systemadministration er den bedste assistent revision, i vores tilfælde revideret.
Et øjebliks tvivlJeg gennemgik manaen, men var ikke helt sikker på, at tiden i Linux kun kan indstilles ur_indstillingstid и sæt tid på dagen, så til den første test valgte jeg alle de "egnede" opkald:
# 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
og kassering s390_runtime_instr, stime, timerfd_create, hvilken auditctl genkendte det ikke, lancerede oprindeligt en revision i form af:
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 utimesEfter at have sikret mig, at der ikke er andre logfiler på logplaceringerne, er jeg interesseret i syscalls Udover disse to brugte jeg kun dem yderligere.
Kører en systemopkaldsrevision ur_indstillingstid и sæt tid på dagen og prøv at ændre datoen:
# auditctl -a exit,always -S clock_settime -S settimeofday && date -s "2019-08-22 12:10:00" && sleep 5 && auditctl -D
Der tilføjes en forsinkelse på fem sekunder, så vores "parasit" med garanti vil rette tiden.
Lad os se på rapporten:
# 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
Her ser vi vores dato og ukendt for os chkcache_processer. Det endte i rapporten ovenfor, fordi aureport sorterede output efter dato ved konvertering fra binær, og hændelsen fandt sted på det tidspunkt, vi satte dato -s "2019-08-22 12:10:00".
Hvem fødte ham?
# 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 - vores parasit er fundet. På trods af dets "ondsindede" adfærd er det umuligt at nægte adgangsstyringssystemet, men jeg vil stadig gerne vide oscam, WTF?
Svaret findes hurtigt i :
#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");
}
Hvor ser det sødt ud her kommenterede ud linje advarsel...
Kilde: www.habr.com