ProHoster > Blog > Administratioun > Wat d'Aufgab méi einfach ass, dest méi dacks maachen ech Feeler

Wat d'Aufgab méi einfach ass, dest méi dacks maachen ech Feeler

Wat d'Aufgab méi einfach ass, dest méi dacks maachen ech Feeler

Dës trivial Aufgab ass e Freideg Nomëtteg entstanen a sollt 2-3 Minutten Zäit huelen. Am Allgemengen, wéi ëmmer.

E Kolleg huet mech gefrot de Skript op sengem Server ze fixéieren. Ech hunn et gemaach, him et iwwerginn an onopfälleg erofgaang: "D'Zäit ass 5 Minutten séier." Loosst de Server d'Synchroniséierung selwer handhaben. Eng hallef Stonn, eng Stonn ass vergaang, an hien huet nach ëmmer gepufft a roueg verflucht.

„Dumm! - Ech hu geduecht, op d'Serverkonsol ze wiesselen - okay, ech huelen eng Paus fir e puer Minutten.

Mol kucken ntp, rdate, sdwdate net installéiert Zäitsyncd behënnert an net lafen.

# 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

Hei wäert ech direkt feststellen datt d'Hardware Zäit richteg ass: et wäert méi einfach sinn weider ze navigéieren.

Dëst ass wou d'Serie vu Feeler ugefaang huet.

Den éischte Feeler. Selbstvertrauen

Klick-Klack...

# 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 ass gutt, d'Zäit ass synchroniséiert, d'Systemzäit entsprécht der Hardware. "Huelt et," sot ech an zréck op mäi Geschäft.

"Wat huelen? - de Kolleg war indignéiert. "Et ass déi selwecht Zäit!"

Wat Dir méi typesch Probleemer léist, ëmsou méi gëtt Äert Denken blénkeg an Dir mengt net méi datt déi Honnertsten oder Tausendsten Situatioun anescht wäert sinn, awer net dës Kéier.

# 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

De System Zäit ass erëm falsch.

Loosst eis nach eng Kéier probéieren:

# 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

Loosst eis et anescht maachen:

# 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

Dat ass wéi:

# 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

D'Zäit ass fir eng Split-Sekonn festgeluecht, a fänkt direkt erëm un ze "rushen".

Zur selwechter Zäit, an de Logbicher, an der Zäit vun esou enger manueller Ännerung, gesi mir nëmmen Systemberichter, datt d'Zäit geännert huet, respektiv an déi richteg/falsch Richtung an heiansdo Resynchroniséieren aus 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

hei

# ps afx | grep "[1]187"
 1187 ?        Ss     0:02 /lib/systemd/systemd --user

Zu dësem Zäitpunkt war et schonn néideg fir de Grond ze sichen, awer iwwer 18 Joer Administratioun huet d'Gehir Statistiken iwwer "Zäit" Feeler gesammelt an, aus Gewunnecht, nees d'Synchroniséierung zouginn.
Loosst eis et komplett ausschalten. 

# 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

an an de Logbicher

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

Resynchroniséieren verschwonnen an soss sinn d'Protokoller onbestänneg.

Iwwerpréift d'Conclusiounen tcpdump op port 123 op all Schnëttplazen. Et gi keng Ufroen, awer d'Zäit leeft nach ëmmer fort.

Feeler zwee. Rush

Et bleift eng Stonn bis d'Enn vun der Aarbechtswoch, an ech wëll net fir de Weekend mat engem triviale ongeléiste Problem fortgoen (passt net op d'Zäit am Code op, den Artikel gouf an den folgenden Deeg geschriwwen ).
An hei nach eng Kéier, anstatt de Grond ze sichen, hunn ech ugefaang ze probéieren mat enger Erklärung zum Resultat ze kommen. Ech soen "erfannen" well egal wéi logesch d'Erklärung fir d'Resultat ass, et ass eng falsch Approche fir de Problem ze léisen.

Dëse Server ass e Streaming Server an konvertéiert den DVB-S2 Stream an IP. Den DVB-S Stream enthält Zäitstempel, sou datt Empfänger, Multiplexer, Scramblers an Fernseher dacks benotze fir d'Systemuhr ze synchroniséieren. DVB-S Board Chauffeuren sinn an de Kärel gebaut, sou datt de schnellsten Wee fir sécherzestellen datt den DVB-S2 Stream ewechgeholl gëtt ass d'Kabelen ze trennen déi vun de "Placken" kommen. Glécklecherweis ass de Server hannert der Mauer, also ass et.

Natierlech, wann d'Logbicher enthale wieren, wat do sollt stoen, wier dat net geschitt, mee méi doriwwer, nach eng Kéier, um Enn vum Artikel.

Gutt, well mir all Satellit Signaler scho geläscht hunn, wäerte mir och terrestresch ewechhuelen - gläichzäiteg zéie mir all d'Netzkabel eraus. De Server gëtt vun der Äussewelt ofgeschnidden a funktionnéiert komplett autonom, awer d'Systemuhr ass nach ëmmer presséiert.

D'Aarbechtswoch ass eriwwer, an den Datum/Zeitproblem selwer ass net kritesch, also kënnt Dir einfach heem goen, awer hei maachen ech en neie Feeler.

Feeler dräi. Conseilleren

Ni! Stellt ni Froen op Forum'en an allgemeng spezialiséiert (a la stackoverflow) Siten, wann d'Äntwert op et méi erfuerdert wéi d'éischt Säit vu Google ze studéieren an eng Mann Säit ze liesen.

Si schécken Iech zréck op Google, liesen dee selwechte Mann a populär erklären d'Regele vum Forum / Site, awer ginn Iech keng Äntwert.

Hei sinn e puer objektiv Faktoren:

  • keen ausser Dir kënnt de Problem och wëssen;
  • keen kann Tester ënner de selwechte Konditiounen wéi Är Exercice

a subjektiv:

  • Dir kënnt net all Input fir d'Léisung vum Problem ginn, well Dir scho mat der "richtiger" Richtung komm sidd an d'Essenz vum Thema presentéiere mat deem fokusséiert ass;
  • de Forman (Moderator, Oldtimer, Admin) huet emmer Recht, wann de Forman falsch ass... bon, du weess...

Wann Dir, wann Dir op Kommentaren äntwert, an de Grenze vum zensuréierte Vokabulär bliwwen ass, dann hutt Dir staark Nerven.

Decisioun

Et ass net néideg Aufgaben an einfach a komplex opzedeelen.

Mir stoppen op eis Erfahrung, Statistiken, Beroder ze vertrauen a fänken un d'Ennresultat net ze "erklären", mee konsequent no de Grond ze sichen.

Well een d'Zäit setzt, muss de entspriechende Systemruff geschéien.

Just wéi an der Softwaredokumentatioun déi bescht Dokumenter d'Quell sinn, sou ass an der Systemadministratioun de beschten Assistent Audit, an eisem Fall iwwerpréift.

E Moment vun ZweiwelEch sinn duerch d'Mana gaang, awer war net ganz sécher datt d'Zäit am Linux nëmmen agestallt ka ginn Auer_Setzeit и gesat Zäit vum Dag, also fir den éischten Test hunn ech all déi "passend" Uriff gewielt:

# 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

an ofginn s390_runtime_instr, stime, timerfd_create, déi auditctl huet et net erkannt, huet am Ufank en Audit a Form lancéiert:

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 utimes

Nodeems Dir sécher sidd, datt et keng aner Logbicher an de Logbicher sinn, déi ech interesséiert syscalls Nieft dësen zwee hunn ech se nëmme weider benotzt.

Lafen e System Call Audit Auer_Setzeit и gesat Zäit vum Dag a probéiert den Datum z'änneren:

# auditctl -a exit,always -S clock_settime -S settimeofday && date -s "2019-08-22 12:10:00" && sleep 5 && auditctl -D

Eng fënnef Sekonnen Verspéidung gëtt bäigefüügt fir datt eise "Parasit" garantéiert ass d'Zäit ze korrigéieren.

Loosst eis de Bericht kucken:

# 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

Hei gesi mer eis Datum an eis onbekannt chkcache_processes. Et ass am Bericht uewen opgehalen well aureport den Ausgang nom Datum sortéiert huet wann Dir vu Binär konvertéiert, an d'Evenement ass geschitt zu der Zäit wou mir gesat hunn Datum -S "2019-08-22 12:10:00".
Wien huet him gebuer?

# 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 - eise Parasit gouf fonnt. Trotz sengem "béiswëllegen" Verhalen ass et onméiglech de bedingte Zougangssystem ze refuséieren, awer ech wéilt ëmmer nach wëssen oscam, WTF?

D'Äntwert ass séier fonnt an Quelltext:

#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");
}

Wéi léif et gesäit hei aus kommentéiert aus Linn Warnung...

Source: will.com

Setzt e Commentaire