ProHoster > Blog > Administrazioa > Zeregin sinpleagoa izan, orduan eta maizago egiten ditut akatsak

Zeregin sinpleagoa izan, orduan eta maizago egiten ditut akatsak

Zeregin sinpleagoa izan, orduan eta maizago egiten ditut akatsak

Zeregin hutsal hau ostiral arratsalde batean sortu zen eta 2-3 minutu behar izan zituen. Orokorrean, beti bezala.

Lankide batek bere zerbitzarian gidoia konpontzeko eskatu zidan. Egin nuen, eman nion eta nahi gabe erori egin nintzen: "Denbora 5 minutu azkarra da". Utzi zerbitzariari sinkronizazioa bera kudeatzen. Ordu erdi, ordu bat pasa zen, eta oraindik puztu eta isil-isilik madarikatu zuen.

β€œErgela! β€” Pentsatu nuen, zerbitzariaren kontsolara aldatuz β€” ados, minutu pare bat gehiago hartuko dut atseden.

Ikus dezagun ntp, rdate, sdwdate instalatu gabe aldiz desgaituta eta ez da martxan.

# 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

Hemen berehala ohartuko naiz hardwarearen ordua zuzena dela: errazago nabigatzea izango da.

Hor hasi zen akats sorta.

Lehenengo akatsa. Auto konfidantza

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

Dena ondo dago, ordua sinkronizatuta dago, sistemaren ordua hardwarearekin bat dator. "Har ezazu", esan nuen eta nire negoziora itzuli nintzen.

β€œZer hartu? - sumindu egin zen lankidea. "Ordu berean da!"

Arazo tipikoak zenbat eta gehiago konpontzen dituzun, orduan eta gehiago keinu egiten da zure pentsamendua eta jada ez duzu uste ehungarren edo milgarren egoera ezberdina izango denik, baina oraingoan ez.

# 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

Sistemaren ordua oker dago berriro.

Saia gaitezen berriro:

# 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

Egin dezagun beste era batera:

# 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

Eta honela:

# 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

Denbora segundo zati batean ezartzen da, eta berehala hasten da berriro "presaka".

Aldi berean, erregistroetan, halako eskuzko aldaketaren unean, ordua aldatu dela sistemaren txostenak baino ez ditugu ikusten, hurrenez hurren, norabide egokian/okerrean eta noizean behin. Berriro sinkronizatzen systemd-timesyncd-etik.

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

Hemen

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

Une honetan, arrazoia bilatu behar zen jada, baina administrazioaren 18 urtetan zehar, garunak "denbora" akatsen estatistikak pilatu ditu eta, ohituraz, berriro sinkronizazioari egozten dio errua.
Itzal dezagun guztiz. 

# 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

eta erregistroetan

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

Berriro sinkronizatzen desagertu eta, bestela, enborrak garbi daude.

Ondorioak egiaztatzea tcpdump 123 atakan interfaze guztietan. Ez dago eskaerarik, baina oraindik denbora ihes egiten ari da.

Bi akatsa. Presa

Ordubete falta da lan astea bukatzeko, eta ez dut astebururako utzi nahi konpondu gabeko arazo hutsal batekin (ez egin arreta kodean dagoen orduari, hurrengo egunetan idatzi da artikulua ).
Eta hemen berriz, arrazoia bilatu beharrean, emaitzari azalpena ematen saiatzen hasi nintzen. β€œAsmatu” esaten dut, emaitzaren azalpena zein logikoa den arren, arazoa konpontzeko ikuspegi akatsa delako.

Zerbitzari hau streaming zerbitzari bat da eta DVB-S2 korrontea IP bihurtzen du. DVB-S korronteak denbora-zigiluak ditu, beraz, hargailuek, multiplexadoreek, nahasgailuek eta telebistek sarri erabiltzen dituzte sistemaren erlojua sinkronizatzeko. DVB-S plaka kontrolatzaileak nukleoan integratuta daude, beraz, DVB-S2 korrontea kentzen dela ziurtatzeko modurik azkarrena "plaketatik" datozen kableak deskonektatzea da. Zorionez, zerbitzaria hormaren atzean dago, beraz.

Noski, erregistroek bertan egon beharko lukeena jaso izan balute, ez zen hori gertatuko, baina gehiago, berriro ere, artikuluaren amaieran.

Bada, dagoeneko satelite seinale guztiak kendu ditugunez, lurrekoak ere kenduko ditugu -aldi berean sareko kable guztiak ateratzen ditugu. Zerbitzaria kanpotik moztu egiten da eta erabat autonomoki funtzionatzen du, baina sistemaren erlojua presaka dabil oraindik.

Lan astea amaitu da, eta data/orduaren arazoa bera ez da kritikoa, beraz etxera joan zaitezke, baina hemen akats berri bat egiten dut.

Hiru akatsa. Aholkulariak

Inoiz ez! Inoiz ez egin galderarik foroetan eta gune espezializatu orokorretan (stackoverflow-ean) erantzunak Google-ren lehen orria aztertzea eta man orri bat irakurtzea baino gehiago eskatzen badu.

Googlera itzuliko zaituzte, gizon bera irakurri eta foro/gunearen arauak azalduko dituzte, baina ez dizute erantzunik emango.

Hona hemen faktore objektibo batzuk:

  • inork ezin du arazoa ezagutu izan ezik;
  • inork ezin ditu probak egin zure baldintza berdinetan

eta subjektiboa:

  • Agian ez duzu arazoa konpontzeko ekarpen guztiak emango, dagoeneko norabide "egokia" asmatu duzulako eta gaiaren funtsa aurkezten ari zarelako horretara bideratuz;
  • foruzainak (moderatzailea, zaharrena, administratzailea) beti du arrazoia, foruzaina oker bada... bueno, badakizu...

Iruzkinei erantzutean, zentsuraturiko hiztegiaren mugen barruan geratu bazara, orduan nerbio sendoak dituzu.

Erabaki

Ez dago zeregin sinple eta konplexuetan banatu beharrik.

Gure esperientzian, estatistiketan, aholkularietan fidatzeari uzten diogu eta amaierako emaitza ez "azaltzen" hasten gara, arrazoia etengabe bilatzen baizik.

Norbaitek ordua ezartzen duenez, dagokion sistema-deia gertatu behar da.

Softwarearen dokumentazioan dokumentu onenak iturriak diren bezala, sistemaren administrazioan laguntzailerik onena auditoria da, gure kasuan. ikuskatuta.

Zalantza momentu batManatik pasatu nintzen, baina ez nengoen guztiz ziur Linuxen ordua soilik ezarri daitekeenik erloju_ordua ΠΈ egunaren ezartzea, beraz, lehenengo probarako deialdi "egokiak" guztiak aukeratu ditut:

# 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

eta baztertzea s390_runtime_instr, stime, timerfd_create, zein auditorctl ez zuen aintzat hartu, hasiera batean auditoria bat abiarazi zuen honela:

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

Interesatzen zaizkidan erregistro-kokapenetan beste erregistrorik ez dagoela ziurtatu ondoren syscall-ak Bi hauez gain, gehiago erabili ditut.

Sistema-deien auditoria bat exekutatzen erloju_ordua ΠΈ egunaren ezartzea eta saiatu data aldatzen:

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

Bost segundoko atzerapena gehitzen da, gure "parasitoak" denbora zuzentzeko bermatuta egon dadin.

Ikus dezagun txostena:

# 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

Hemen ikusten dugu gure data eta guretzat ezezaguna chkcache_prozesuak. Goiko txostenean amaitu zen, aureport-ek irteera dataren arabera ordenatu zuelako bitarretik bihurtzean, eta gertaera ezarri genuen unean gertatu zen. data -s "2019-08-22 12:10:00".
Nork erditu zuen?

# 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 - gure bizkarroia aurkitu da. Jokaera "maltzurra" izan arren, ezinezkoa da baldintzapeko sarbide-sistemari uko egitea, baina hala ere jakin nahiko nuke oscam, WTF?

Erantzuna azkar aurkitzen da iturburu-kodeak:

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

Zein polita den hemen iruzkindu zuen lerroa abisua...

Iturria: www.habr.com

Gehitu iruzkin berria