කාර්යය සරල වන තරමට මම බොහෝ විට වැරදි කරමි

මෙම සුළු කාර්යය සිකුරාදා සවස් වරුවේ ඇති වූ අතර විනාඩි 2-3 ක කාලයක් ගත විය යුතුය. පොදුවේ, සෑම විටම මෙන්.

සගයෙක් මගෙන් ස්ක්‍රිප්ට් එක එයාගේ සර්වර් එකේ හදන්න කිව්වා. මම එය කළා, එය ඔහුට භාර දී නොදැනුවත්වම පහතට දැමුවෙමි: "කාලය විනාඩි 5 වේගවත්." සේවාදායකයට සමමුහුර්තකරණය හැසිරවීමට ඉඩ දෙන්න. පැය භාගයක්, පැයක් ගෙවී ගිය අතර, ඔහු තවමත් පිම්බෙමින් නිහඬව ශාප කළේය.

“මෝඩයා! - මම හිතුවා, සර්වර් කොන්සෝලයට මාරු වෙනවා - හරි, මම තව විනාඩි කිහිපයක් විවේක ගන්නම්."

අපි බලමු ntp, rdate, sdwdate ස්ථාපනය කර නැත timeyncd ආබාධිත සහ ධාවනය නොවේ.

# 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

මෙන්න මම දෘඪාංග කාලය නිවැරදි බව වහාම සටහන් කරමි: එය තවදුරටත් සැරිසැරීමට පහසු වනු ඇත.

වැරදි මාලාව පටන් ගත්තේ මෙතැනින්.

පළමු වැරැද්ද. ආත්ම විශ්වාසය

ක්ලික්-ක්ලැක්...

# 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

සෑම දෙයක්ම හොඳයි, කාලය සමමුහුර්ත කර ඇත, පද්ධතියේ කාලය දෘඪාංග එකට ගැලපේ. "එය ගන්න" කියා මම නැවත මගේ ව්‍යාපාරයට ගියෙමි.

"මොනවා ගන්නද? - සගයා කෝපයට පත් විය. "එය එකම වේලාවයි!"

ඔබ සාමාන්‍ය ගැටලු විසඳන තරමට, ඔබේ සිතුවිල්ල අඳුරු වන අතර සියවෙනි හෝ දහස්වන තත්වය වෙනස් වනු ඇතැයි ඔබ තවදුරටත් සිතන්නේ නැත, නමුත් මෙවර නොවේ.

# 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

පද්ධතියේ කාලය නැවතත් වැරදියි.

නැවත උත්සහ කරමු:

# 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

අපි එය වෙනස් ආකාරයකින් කරමු:

# 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

සහ මේ වගේ:

# 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

තත්පරයකට බෙදීම සඳහා කාලය සකසා ඇති අතර, වහාම නැවත "ඉක්මන්" කිරීමට පටන් ගනී.

ඒ අතරම, ලඝු-සටහන් වල, එවැනි අතින් වෙනස් වන විට, අපට පෙනෙන්නේ කාලය පිළිවෙළින් නිවැරදි/වැරදි දිශාවට සහ ඉඳහිට වෙනස් වූ පද්ධති වාර්තා පමණි. නැවත සමමුහුර්ත කිරීම 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

මෙහි

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

මෙම අවස්ථාවෙහිදී, හේතුව සොයා බැලීම දැනටමත් අවශ්ය විය, නමුත් වසර 18 ක පරිපාලනය තුළ මොළය "කාල" දෝෂ පිළිබඳ සංඛ්යාලේඛන රැස් කර ඇති අතර, පුරුද්දෙන්, නැවතත් සමමුහුර්තකරණයට දොස් පවරයි.
අපි එය සම්පූර්ණයෙන්ම නිවා දමමු.

# 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

සහ ලඝු-සටහන් වල

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

නැවත සමමුහුර්ත කිරීම අතුරුදහන් වී ඇති අතර එසේ නොමැතිනම් ලොගයන් පෞරාණික වේ.

නිගමන පරීක්ෂා කිරීම tcpdump සියලුම අතුරුමුහුණත් වල වරාය 123 මත. ඉල්ලීම් නැත, නමුත් කාලය තවමත් ගෙවී යයි.

දෝෂය දෙක. කඩිමුඩියේ

වැඩ සතිය අවසන් වීමට පැයක් ඉතිරිව ඇති අතර නොවිසඳුණු සුළු ගැටලුවක් සමඟ සති අන්තයට යාමට මට අවශ්‍ය නැත (කෝඩ් එකේ වේලාව ගැන අවධානය යොමු නොකරන්න, ලිපිය ලියා ඇත්තේ ඊළඟ දිනවල ය. )
මෙන්න නැවතත්, හේතුව සොයනවා වෙනුවට, මම ප්රතිඵලය සඳහා පැහැදිලි කිරීමක් ඉදිරිපත් කිරීමට උත්සාහ කිරීමට පටන් ගත්තා. මම "නිපදවන්න" කියන්නේ ප්‍රතිඵලය සඳහා පැහැදිලි කිරීම කොතරම් තාර්කික වුවත්, එය ගැටලුව විසඳීම සඳහා දෝෂ සහිත ප්‍රවේශයක් වන බැවිනි.

මෙම සේවාදායකය ප්‍රවාහ සේවාදායකයක් වන අතර DVB-S2 ප්‍රවාහය IP බවට පරිවර්තනය කරයි. DVB-S ප්‍රවාහයේ වේලා මුද්‍රා අඩංගු වේ, එබැවින් ග්‍රාහක, මල්ටිප්ලෙක්සර්, ස්ක්‍රැම්බලර් සහ රූපවාහිනී බොහෝ විට පද්ධති ඔරලෝසුව සමමුහුර්ත කිරීමට ඒවා භාවිතා කරයි. DVB-S පුවරු ධාවක කර්නලය තුළට ගොඩනගා ඇත, එබැවින් DVB-S2 ප්‍රවාහය ඉවත් කර ඇති බව සහතික කිරීමට වේගවත්ම ක්‍රමය වන්නේ “තහඩු” වලින් එන කේබල් විසන්ධි කිරීමයි. වාසනාවකට මෙන්, සේවාදායකය බිත්තිය පිටුපස ඇත, එසේ විය යුතුය.

ඇත්ත වශයෙන්ම, ලඝු-සටහන් එහි තිබිය යුතු දේ අඩංගු වූයේ නම්, මෙය සිදු නොවනු ඇත, නමුත් ඒ ගැන වැඩි විස්තර, නැවතත්, ලිපිය අවසානයේ.

හොඳයි, අපි දැනටමත් සියලුම චන්ද්‍රිකා සංඥා ඉවත් කර ඇති බැවින්, අපි භූමිෂ්ඨ ඒවා ද ඉවත් කරන්නෙමු - ඒ සමඟම අපි සියලු ජාල කේබල් අදින්නෙමු. සේවාදායකය බාහිර ලෝකයෙන් විසන්ධි වී සම්පූර්ණයෙන්ම ස්වයංක්‍රීයව ක්‍රියා කරයි, නමුත් පද්ධති ඔරලෝසුව තවමත් කඩිමුඩියේ පවතී.

වැඩ සතිය අවසන් වී ඇති අතර, දිනය/වේලාව ගැටලුවම තීරණාත්මක නොවේ, එබැවින් ඔබට නිකම්ම ගෙදර යා හැක, නමුත් මෙහිදී මම අලුත් වැරැද්දක් කරමි.

දෝෂය තුන. උපදේශකයන්

කවදාවත්! Google හි පළමු පිටුව අධ්‍යයනය කිරීමට සහ තනි පුද්ගල පිටුවක් කියවීමට වඩා පිළිතුරක් අවශ්‍ය නම් කිසිවිටෙක සංසද සහ සාමාන්‍ය විශේෂිත (a la stackoverflow) අඩවි වල ප්‍රශ්න අසන්න එපා.

ඔවුන් ඔබව නැවත Google වෙත යවා, එම මිනිසාම කියවා සංසදයේ/අඩවියේ නීති ජනප්‍රිය ලෙස පැහැදිලි කරයි, නමුත් ඔබට පිළිතුරක් ලබා නොදෙනු ඇත.

වෛෂයික සාධක කිහිපයක් මෙන්න:

• ඔබ හැර වෙන කිසිවෙකුට ගැටලුව දැනගත නොහැක;
• ඔබගේ කොන්දේසි යටතේ කිසිවෙකුට පරීක්ෂණ පැවැත්විය නොහැක

සහ ආත්මීය:

• ඔබ දැනටමත් "නිවැරදි" දිශාව ඉදිරිපත් කර ඇති නිසාත්, ගැටලුවේ සාරය ඒ කෙරෙහි අවධානය යොමු කරමින් ඉදිරිපත් කරන නිසාත්, ගැටලුව විසඳීම සඳහා ඔබට සියලු ආදාන ලබා නොදිය හැකිය;
• ප්‍රධානියා (මොඩරේටර්, පරණ-ටයිමර්, ඇඩ්මින්) සැමවිටම නිවැරදිය, ප්‍රධානියා වැරදි නම්... හොඳයි, ඔබ දන්නවා...

අදහස්වලට පිළිතුරු දෙන විට, ඔබ වාරණය කළ වචන මාලාවේ සීමාවන් තුළ රැඳී සිටියේ නම්, ඔබට ශක්තිමත් ස්නායු ඇත.

තීරණය

කාර්යයන් සරල හා සංකීර්ණ ලෙස බෙදීමට අවශ්ය නැත.

අපි අපගේ අත්දැකීම්, සංඛ්‍යාලේඛන, උපදේශකයින් මත විශ්වාසය තැබීම නවත්වා අවසාන ප්‍රති result ලය “පැහැදිලි කිරීමට” නොව, හේතුව සොයා බැලීමට පටන් ගනිමු.

යමෙකු වේලාව නියම කරන බැවින්, ඊට අනුරූප පද්ධති ඇමතුම සිදුවිය යුතුය.

මෘදුකාංග ප්‍රලේඛනයේදී හොඳම ලේඛන මූලාශ්‍ර වන්නා සේම, පද්ධති පරිපාලනයේදී හොඳම සහායකයා වන්නේ විගණනයයි. විගණනය කරන ලදී.

සැක සහිත මොහොතක්මම mana හරහා ගිය නමුත් Linux හි කාලය පමණක් සැකසිය හැකි බව සම්පූර්ණයෙන්ම විශ්වාස නැත ඔරලෝසු_සැකසුම් වේලාව и settimeofday, එබැවින් පළමු පරීක්ෂණය සඳහා මම සියලු "සුදුසු" ඇමතුම් තෝරා ගත්තෙමි:

# 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

සහ බැහැර කිරීම s390_runtime_instr, stime, timerfd_create, කුමන auditctl එය හඳුනා නොගත් අතර, මුලින් පෝරමයේ විගණනයක් දියත් කළේය:

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

මා උනන්දු වන ලොග් ස්ථානවල වෙනත් ලඝු-සටහන් නොමැති බව තහවුරු කර ගැනීමෙන් පසුව සිස්කල් මේ දෙකට අමතරව මම ඒවා පමණක් තවදුරටත් භාවිතා කළෙමි.

පද්ධති ඇමතුම් විගණනයක් ක්‍රියාත්මක කිරීම ඔරලෝසු_සැකසුම් වේලාව и settimeofday සහ දිනය වෙනස් කිරීමට උත්සාහ කරන්න:

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

අපගේ "පරපෝෂිතයා" කාලය නිවැරදි කිරීමට සහතික වන පරිදි තත්පර පහක ප්රමාදයක් එකතු කරනු ලැබේ.

වාර්තාව දෙස බලමු:

# 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

මෙන්න අපි අපේ දිනය සහ අප නොදන්නා chkcache_processes. එය ඉහත වාර්තාවේ අවසන් වූයේ aureport ද්විමය වලින් පරිවර්තනය කිරීමේදී ප්‍රතිදානය දිනය අනුව වර්ග කළ නිසා සහ අප විසින් සැකසූ අවස්ථාවේ සිදුවීම සිදු වූ බැවිනි. දිනය -s "2019-08-22 12:10:00".
ඔහුව බිහි කළේ කවුද?

# 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 - අපේ පරපෝෂිතයා සොයාගෙන ඇත. එහි “ද්වේෂ සහගත” හැසිරීම තිබියදීත්, කොන්දේසි සහිත ප්‍රවේශ පද්ධතිය ප්‍රතික්ෂේප කළ නොහැක, නමුත් මම තවමත් දැන ගැනීමට කැමතියි oscam, WTF?

පිළිතුර ඉක්මනින් සොයාගත හැකිය මූලාශ්ර කේත:

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

මෙතන කොච්චර ලස්සනයි වගේ අදහස් දැක්වීය රේඛාව අනතුරු ඇඟවීම...

මූලාශ්රය: www.habr.com