Ez a triviális feladat egy péntek délután merült fel, és 2-3 percet kellett volna igénybe vennie. Általában, mint mindig.
Egy kolléga megkért, hogy javítsam ki a szkriptet a szerverén. Megcsináltam, odaadtam neki, és akaratlanul is ledobtam: "5 perccel gyors az idő." Hagyja, hogy a szerver maga kezelje a szinkronizálást. Fél óra, egy óra telt el, ő még mindig püfölte és halkan káromkodott.
"Hülye! – gondoltam, amikor a szerverkonzolra váltottam – oké, tartok még egy pár perc szünetet.
Nézzük ntp, rdate, sdwdate nem telepített timeSyncd letiltva és nem fut.
# 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
Itt azonnal megjegyzem, hogy a hardveridő helyes: könnyebb lesz tovább navigálni.
Itt kezdődött a hibák sorozata.
Az első hiba. Önbizalom
Klikk-csat...
# 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
Minden rendben van, az idő szinkronizálva van, a rendszeridő megegyezik a hardveresével. – Fogd – mondtam, és visszatértem a dolgomhoz.
„Mit vegyél? - háborodott fel a kolléga. – Ugyanaz az idő!
Minél többet oldasz meg tipikus problémákat, annál jobban összezavarodik a gondolkodásod, és már nem gondolod, hogy a századik vagy ezredik helyzet más lesz, de most nem.
# 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
Megint rossz a rendszeridő.
Próbáljuk meg újra:
# 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
Csináljuk másképp:
# 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
De így:
# 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
Az idő a másodperc töredékére van beállítva, és azonnal újra „rohanni” kezd.
Ugyanakkor a naplókban egy ilyen kézi változtatáskor csak rendszerjelentéseket látunk arról, hogy az idő helyes/rossz irányba változott, illetve alkalmanként. Újraszinkronizálás a systemd-timesyncd-ből.
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
itt
# ps afx | grep "[1]187"
1187 ? Ss 0:02 /lib/systemd/systemd --user
Ekkor már keresni kellett az okot, de 18 évnyi adminisztráció alatt az agy statisztikát halmozott fel az „időbeli” hibákról, és megszokásból ismét a szinkronizálást okolja.
Kapcsoljuk ki teljesen.
# 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
és a naplókban
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
Újraszinkronizálás eltűnt, és egyébként a rönkök érintetlenek.
A következtetések ellenőrzése tcpdump a 123-as porton minden interfészen. Nincsenek kérések, de az idő még mindig rohan.
Hiba kettő. Rohanás
Egy óra van hátra a munkahét végéig, és nem akarok elmenni hétvégére egy triviális megoldatlan problémával (ne figyelj a kódban lévő időre, a cikk a következő napokban készült ).
És itt is, ahelyett, hogy az okot kerestem volna, megpróbáltam magyarázatot találni az eredményre. Azért mondom, hogy „találj fel”, mert bármennyire is logikus az eredmény magyarázata, ez egy hibás megközelítés a probléma megoldásához.
Ez a szerver egy streaming szerver, és a DVB-S2 adatfolyamot IP-vé alakítja. A DVB-S adatfolyam időbélyegeket tartalmaz, így a vevőkészülékek, multiplexerek, kódolók és televíziók gyakran használják őket a rendszeróra szinkronizálására. A DVB-S kártya meghajtói a kernelbe vannak beépítve, így a DVB-S2 adatfolyam eltávolításának leggyorsabb módja a „lemezekről” érkező kábelek leválasztása. Szerencsére a szerver a fal mögött van, hát legyen.
Természetesen, ha a naplók tartalmazták volna azt, aminek ott lennie kell, ez nem történt volna meg, de erről ismét a cikk végén.
Nos, mivel már eltávolítottuk az összes műholdjelet, a földieket is eltávolítjuk - egyúttal kihúzzuk az összes hálózati kábelt. A szerver elzáródik a külvilágtól és teljesen önállóan működik, de a rendszeróra még mindig siet.
A munkahétnek vége, és maga a dátum/idő probléma nem kritikus, úgyhogy mehet haza, de itt elkövetek egy új hibát.
Három hiba. Tanácsadók
Soha! Soha ne tegyen fel kérdéseket fórumokon és általánosan szakosodott (a la stackoverflow) webhelyeken, ha a válasz nem igényel többet, mint a Google első oldalának tanulmányozása és egy kézikönyv oldal elolvasása.
Visszaküldenek a Google-be, elolvassák ugyanazt az embert, és népszerűsítik a fórum/oldal szabályait, de nem adnak választ.
Íme néhány objektív tényező:
- rajtad kívül senki sem tudhatja a problémát;
- senki sem végezhet vizsgálatokat olyan feltételek mellett, mint az Öné
és szubjektív:
- előfordulhat, hogy nem ad meg minden inputot a probléma megoldásához, mert már kitalálta a „helyes” irányt, és arra fókuszálva mutatja be a kérdés lényegét;
- a művezetőnek (moderátor, old-timer, admin) mindig igaza van, ha az elöljárónak nincs igaza... hát tudod...
Ha a kommentekre válaszolva a cenzúrázott szókincs határain belül maradtál, akkor erős idegeid vannak.
döntés
Nem szükséges egyszerű és összetett feladatokra osztani a feladatokat.
Nem hagyatkozunk tapasztalatainkra, statisztikáinkra, tanácsadóinkra, és nem a végeredményt kezdjük „megmagyarázni”, hanem következetesen keresni az okot.
Mivel valaki beállítja az időt, a megfelelő rendszerhívásnak meg kell történnie.
Ahogy a szoftverdokumentációban a legjobb dokumentumok a források, úgy a rendszeradminisztrációban is a legjobb asszisztens az audit, esetünkben auditd.
Egy pillanatnyi kétségVégigmentem a manán, de nem voltam teljesen biztos benne, hogy Linuxon csak az időt lehet beállítani clock_settime и beállított időpont, így az első teszthez az összes „megfelelő” hívást kiválasztottam:
# 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
és eldobni s390_runtime_instr, stime, timerfd_create, melyik auditctl nem ismerte fel, kezdetben ellenőrzést indított a következő formában:
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 utimesMiután megbizonyosodott arról, hogy nincs más napló azokon a naplóhelyeken, amelyek érdekelnek syscalls A kettőn kívül csak őket használtam tovább.
Rendszerhívás audit futtatása clock_settime и beállított időpont és próbáld megváltoztatni a dátumot:
# auditctl -a exit,always -S clock_settime -S settimeofday && date -s "2019-08-22 12:10:00" && sleep 5 && auditctl -D
Öt másodperces késleltetést adunk hozzá, így a „parazitunk” garantáltan kijavítja az időt.
Lássuk a riportot:
# 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
Itt látjuk a miénket adat és számunkra ismeretlen chkcache_processes. A fenti jelentésbe került, mert az aureport dátum szerint rendezte a kimenetet a binárisból való konvertáláskor, és az esemény az általunk beállított időpontban történt. dátum -s "2019-08-22 12:10:00".
Ki szülte őt?
# 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 - Megtalálták a parazitánkat. A „rosszindulatú” viselkedés ellenére lehetetlen megtagadni a feltételes hozzáférési rendszert, de azért szeretném tudni oscam, WTF?
A válasz gyorsan megtalálható benne :
#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");
}
Milyen aranyosan néz ki itt kommentálta vonal Figyelem...
Forrás: will.com