🥇Kung mas simple ang gawain, mas madalas akong magkamali

Ang maliit na gawaing ito ay bumangon noong Biyernes ng hapon at dapat tumagal ng 2-3 minuto. Sa pangkalahatan, gaya ng lagi.

Hiniling sa akin ng isang kasamahan na ayusin ang script sa kanyang server. Ginawa ko ito, ibinigay sa kanya at hindi sinasadyang bumaba: "Mabilis ang oras ng 5 minuto." Hayaang pangasiwaan ng server ang mismong pag-synchronize. Lumipas ang kalahating oras, isang oras, yumuko pa rin siya at tahimik na nagmura.

"Bobo! — Naisip ko, lumipat sa server console — okay, magpapahinga muna ako ng ilang minuto.”

Tingnan natin ntp, rdate, sdwdate hindi naka-install Timesyncd may kapansanan at hindi tumatakbo.

# 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

Dito ko agad mapapansin na ang oras ng hardware ay tama: mas madaling mag-navigate pa.

Dito nagsimula ang sunod-sunod na pagkakamali.

Ang unang pagkakamali. Kumpiyansa sa sarili

Click-clock...

# 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

Ang lahat ay maayos, ang oras ay naka-synchronize, ang oras ng system ay tumutugma sa hardware. "Take it," sabi ko at bumalik sa aking negosyo.

“Kunin mo ano? - ang kasamahan ay nagalit. "Sabay na oras!"

Kapag mas nalutas mo ang mga karaniwang problema, mas nagiging kumukurap ang iyong pag-iisip at hindi mo na iniisip na ang ika-XNUMX o ika-libong sitwasyon ay magiging iba, ngunit hindi sa pagkakataong ito.

# 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

Mali na naman ang system time.

Subukan nating muli:

# 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

Gawin natin ito nang iba:

# 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

At tulad nito:

# 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

Ang oras ay nakatakda para sa isang split second, at agad na magsisimulang "magmadali" muli.

Kasabay nito, sa mga log, sa oras ng naturang manu-manong pagbabago, nakikita lang namin ang mga ulat ng system na ang oras ay nagbago, ayon sa pagkakabanggit, sa tama/maling direksyon at paminsan-minsan. Muling nagsi-sync mula sa 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

dito

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

Sa puntong ito, kailangan nang hanapin ang dahilan, ngunit sa loob ng 18 taon ng pangangasiwa, ang utak ay naipon ang mga istatistika sa mga "oras" na mga pagkakamali at, sa labas ng ugali, muling sinisisi ang pag-synchronize.
I-off natin ito ng tuluyan.

# 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

at sa mga tala

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

Muling nagsi-sync nawala at kung hindi man ay malinis ang mga log.

Sinusuri ang mga konklusyon tcpdump sa port 123 sa lahat ng mga interface. Walang mga kahilingan, ngunit tumatakbo pa rin ang oras.

Dalawang error. Magmadali

May isang oras na natitira bago matapos ang linggo ng trabaho, at hindi ko nais na umalis para sa katapusan ng linggo na may isang maliit na problema na hindi nalutas (huwag pansinin ang oras sa code, ang artikulo ay isinulat sa mga susunod na araw ).
At heto muli, sa halip na hanapin ang dahilan, sinimulan kong subukang magkaroon ng paliwanag para sa resulta. Sinasabi ko na "imbento" dahil kahit gaano ka lohikal ang paliwanag para sa resulta, ito ay isang maling diskarte sa paglutas ng problema.

Ang server na ito ay isang streaming server at kino-convert ang DVB-S2 stream sa IP. Ang stream ng DVB-S ay naglalaman ng mga timestamp, kaya ang mga receiver, multiplexer, scrambler at telebisyon ay kadalasang ginagamit ang mga ito upang i-synchronize ang system clock. Ang mga driver ng board ng DVB-S ay binuo sa kernel, kaya ang pinakamabilis na paraan upang matiyak na ang stream ng DVB-S2 ay tinanggal ay ang pagdiskonekta sa mga cable na nagmumula sa "mga plato". Buti na lang at nasa likod ng pader ang server, so be it.

Siyempre, kung ang mga log ay naglalaman ng kung ano ang dapat doon, hindi ito mangyayari, ngunit higit pa sa iyon, muli, sa dulo ng artikulo.

Buweno, dahil tinanggal na namin ang lahat ng mga signal ng satellite, aalisin din namin ang mga terrestrial - kasabay nito ay binubunot namin ang lahat ng mga cable ng network. Ang server ay naputol mula sa labas ng mundo at ganap na gumagana nang nakapag-iisa, ngunit ang orasan ng system ay nagmamadali pa rin.

Ang linggo ng trabaho ay tapos na, at ang petsa/oras na isyu mismo ay hindi kritikal, kaya maaari kang umuwi, ngunit dito ako ay gumawa ng isang bagong pagkakamali.

Tatlong error. Mga tagapayo

Hindi kailanman! Huwag kailanman magtanong sa mga forum at pangkalahatang dalubhasa (a la stackoverflow) na mga site kung ang sagot dito ay nangangailangan ng higit pa sa pag-aaral sa unang pahina ng Google at pagbabasa ng isang man page.

Ibabalik ka nila sa Google, babasahin ang parehong tao at tanyag na ipaliwanag ang mga patakaran ng forum/site, ngunit hindi ka bibigyan ng sagot.

Narito ang ilang layunin na mga kadahilanan:

walang sinuman maliban sa iyo ang makakaalam ng problema;
walang sinuman ang maaaring magsagawa ng mga pagsubok sa ilalim ng parehong mga kondisyon tulad ng sa iyo

at subjective:

maaaring hindi mo ibigay ang lahat ng input para sa paglutas ng problema, dahil nakaisip ka na ng "tamang" direksyon at inilalahad ang esensya ng isyu na nakatuon dito;
laging tama ang foreman (moderator, old-timer, admin), kung mali ang foreman... well, you know...

Kung, kapag tumugon sa mga komento, nanatili ka sa loob ng mga limitasyon ng na-censor na bokabularyo, kung gayon mayroon kang malakas na nerbiyos.

desisyon

Hindi na kailangang hatiin ang mga gawain sa simple at kumplikado.

Huminto kami sa pag-asa sa aming karanasan, istatistika, tagapayo at nagsimulang hindi "ipaliwanag" ang resulta, ngunit patuloy na hanapin ang dahilan.

Dahil may nagtakda ng oras, dapat mangyari ang kaukulang tawag sa system.

Tulad ng sa dokumentasyon ng software ang pinakamahusay na mga dokumento ay ang mga mapagkukunan, kaya sa pamamahala ng system ang pinakamahusay na katulong ay pag-audit, sa aming kaso na-audit.

Isang sandali ng pagdududaDumaan ako sa mana, ngunit hindi lubos na sigurado na ang oras sa Linux ay maaari lamang itakda clock_settime и settimeofday, kaya para sa unang pagsubok ay pinili ko ang lahat ng "angkop" na tawag:

# 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

at pagtatapon s390_runtime_instr, stime, timerfd_create, na auditctl hindi ito nakilala, sa una ay naglunsad ng isang pag-audit sa form:

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

Matapos matiyak na walang ibang mga log sa mga lokasyon ng log na interesado ako syscalls Bukod sa dalawang ito, sila lang ang ginamit ko.

Pagpapatakbo ng system call audit clock_settime и settimeofday at subukang baguhin ang petsa:

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

Ang isang limang segundong pagkaantala ay idinagdag upang ang aming "parasite" ay garantisadong itama ang oras.

Tingnan natin ang ulat:

# 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

Dito natin makikita ang ating petsa at hindi natin kilala chkcache_processes. Napunta ito sa ulat sa itaas dahil inayos ng aureport ang output ayon sa petsa kapag nagko-convert mula sa binary, at naganap ang kaganapan sa oras na itinakda namin petsa -s "2019-08-22 12:10:00".
Sino ang nagsilang sa kanya?

# 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 - natagpuan na ang ating parasito. Sa kabila ng "malisyosong" pag-uugali nito, imposibleng tanggihan ang conditional access system, ngunit gusto ko pa ring malaman oscam, WTF?

Ang sagot ay mabilis na matatagpuan sa source code:

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

Ang cute naman tignan dito nagkomento linya babala...

Pinagmulan: www.habr.com

Kung mas simple ang gawain, mas madalas akong nagkakamali

Ang unang pagkakamali. Kumpiyansa sa sarili

Dalawang error. Magmadali

Tatlong error. Mga tagapayo

desisyon

Magdagdag ng komento Kanselahin ang sumagot