កិច្ចការកាន់តែសាមញ្ញ ខ្ញុំកាន់តែធ្វើខុសញឹកញាប់

កិច្ចការតូចតាចនេះបានកើតឡើងនៅរសៀលថ្ងៃសុក្រ ហើយគួរតែចំណាយពេល 2-3 នាទី។ ជាទូទៅដូចរាល់ដង។

សហសេវិកម្នាក់បានសុំឱ្យខ្ញុំជួសជុលស្គ្រីបនៅលើម៉ាស៊ីនមេរបស់គាត់។ ខ្ញុំបានធ្វើវា ប្រគល់វាទៅគាត់ ហើយទម្លាក់ដោយអចេតនា៖ "ពេលវេលាគឺលឿន 5 នាទី" ។ អនុញ្ញាតឱ្យម៉ាស៊ីនមេគ្រប់គ្រងការធ្វើសមកាលកម្មដោយខ្លួនឯង។ កន្លះម៉ោង មួយម៉ោងកន្លងផុតទៅ គាត់នៅតែព្រឺសម្បុរ ហើយជេរយ៉ាងស្ងៀមស្ងាត់។

“ល្ងង់! — ខ្ញុំគិតថា ប្តូរទៅកុងសូលម៉ាស៊ីនមេ — មិនអីទេ ខ្ញុំនឹងសម្រាកពីរបីនាទីទៀត។”

សូម​មើល ntp, rdate, sdwdate មិនបានដំឡើង ស៊ីនស៊ី បិទនិងមិនដំណើរការ។

# 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

នៅទីនេះខ្ញុំនឹងកត់សម្គាល់ភ្លាមៗថាពេលវេលាផ្នែករឹងគឺត្រឹមត្រូវ៖ វានឹងកាន់តែងាយស្រួលក្នុងការរុករកបន្ថែមទៀត។

នេះគឺជាកន្លែងដែលស៊េរីនៃកំហុសបានចាប់ផ្តើម។

កំហុសដំបូង។ ទំនុកចិត្ត​លើ​ខ្លួនឯង

ចុច-click...

# 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 ត្រូវបានដកចេញគឺត្រូវផ្តាច់ខ្សែដែលមកពី "ចាន"។ ជាសំណាងល្អ ម៉ាស៊ីនមេស្ថិតនៅខាងក្រោយជញ្ជាំង ដូច្នេះត្រូវ។

ជាការពិតណាស់ ប្រសិនបើកំណត់ហេតុមានផ្ទុកនូវអ្វីដែលគួរនៅទីនោះ រឿងនេះនឹងមិនកើតឡើងនោះទេ ប៉ុន្តែបន្ថែមលើនោះ ម្តងទៀតនៅចុងបញ្ចប់នៃអត្ថបទ។

ជាការប្រសើរណាស់ ដោយសារយើងបានដកសញ្ញាផ្កាយរណបទាំងអស់រួចហើយ យើងក៏នឹងដកសញ្ញានៅលើដីផងដែរ - ក្នុងពេលជាមួយគ្នានេះ យើងដកខ្សែបណ្តាញទាំងអស់ចេញ។ ម៉ាស៊ីនមេត្រូវបានកាត់ផ្តាច់ពីពិភពខាងក្រៅ ហើយដំណើរការដោយស្វ័យភាពទាំងស្រុង ប៉ុន្តែនាឡិកាប្រព័ន្ធនៅតែប្រញាប់។

សប្តាហ៍ការងារបានបញ្ចប់ហើយ ហើយបញ្ហាកាលបរិច្ឆេទ/ម៉ោងខ្លួនឯងមិនសំខាន់ទេ ដូច្នេះអ្នកអាចត្រឡប់ទៅផ្ទះបាន ប៉ុន្តែនៅទីនេះខ្ញុំធ្វើខុសថ្មី។

កំហុសបី។ ទីប្រឹក្សា

មិនដែល! កុំសួរសំណួរនៅលើវេទិកា និងគេហទំព័រឯកទេសទូទៅ (a la stackoverflow) ប្រសិនបើចម្លើយចំពោះវាទាមទារច្រើនជាងការសិក្សាទំព័រទីមួយរបស់ Google និងអានទំព័រមនុស្សតែមួយ។

ពួកគេនឹងបញ្ជូនអ្នកត្រឡប់ទៅ Google វិញ អានបុរសដូចគ្នា និងពន្យល់យ៉ាងពេញនិយមអំពីច្បាប់នៃវេទិកា/គេហទំព័រ ប៉ុន្តែនឹងមិនផ្តល់ចម្លើយដល់អ្នកទេ។

នេះគឺជាកត្តាគោលបំណងមួយចំនួន៖

• គ្មាននរណាម្នាក់ទេលើកលែងតែអ្នកអាចដឹងពីបញ្ហាផងដែរ។
• គ្មាននរណាម្នាក់អាចធ្វើតេស្តក្រោមលក្ខខណ្ឌដូចគ្នានឹងអ្នកទេ។

និងប្រធានបទ៖

• អ្នកប្រហែលជាមិនផ្តល់ការបញ្ចូលទាំងអស់សម្រាប់ការដោះស្រាយបញ្ហានោះទេ ពីព្រោះអ្នកបានបង្កើតទិសដៅ "ត្រឹមត្រូវ" រួចហើយ ហើយកំពុងបង្ហាញខ្លឹមសារនៃបញ្ហាដែលផ្តោតលើវា;
• មេការ (អ្នកសម្របសម្រួល អ្នកចាស់ អ្នកគ្រប់គ្រង) តែងតែត្រូវ បើមេដឹកនាំខុស... ដឹងទេ...

ប្រសិនបើនៅពេលឆ្លើយតបទៅនឹងមតិយោបល់ អ្នកនៅតែស្ថិតក្នុងដែនកំណត់នៃវាក្យសព្ទដែលត្រូវបានត្រួតពិនិត្យ នោះអ្នកមានសរសៃប្រសាទខ្លាំង។

ការសម្រេចចិត្ត

មិនចាំបាច់បែងចែកកិច្ចការទៅជាសាមញ្ញ និងស្មុគស្មាញនោះទេ។

យើងឈប់ពឹងផ្អែកលើបទពិសោធន៍ ស្ថិតិ ទីប្រឹក្សារបស់យើង ហើយចាប់ផ្តើមមិន “ពន្យល់” លទ្ធផលចុងក្រោយ ប៉ុន្តែត្រូវស្វែងរកហេតុផលឱ្យបានជាប់លាប់។

ដោយសារនរណាម្នាក់កំណត់ពេលវេលា ការហៅប្រព័ន្ធដែលត្រូវគ្នាត្រូវតែកើតឡើង។

ដូចនៅក្នុងឯកសារកម្មវិធីដែរ ឯកសារល្អបំផុតគឺជាប្រភព ដូច្នេះក្នុងការគ្រប់គ្រងប្រព័ន្ធ ជំនួយការដ៏ល្អបំផុតគឺសវនកម្ម ក្នុងករណីរបស់យើង សវនកម្ម.

ការសង្ស័យមួយភ្លែតខ្ញុំបានឆ្លងកាត់ mana ប៉ុន្តែមិនប្រាកដទាំងស្រុងថាពេលវេលានៅក្នុងលីនុចអាចត្រូវបានកំណត់តែប៉ុណ្ណោះ clock_settime и កំណត់ម៉ោងនៃថ្ងៃដូច្នេះ​សម្រាប់​ការ​ធ្វើ​តេស្ដ​ដំបូង​ខ្ញុំ​បាន​ជ្រើស​រើស​ការ​ហៅ​ទូរស័ព្ទ "សមរម្យ" ទាំង​អស់​:

# 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 -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

បន្ទាប់ពីធ្វើឱ្យប្រាកដថាមិនមានកំណត់ហេតុផ្សេងទៀតនៅក្នុងទីតាំងកំណត់ហេតុដែលខ្ញុំចាប់អារម្មណ៍ សំឡេងរោទ៍ ក្រៅ​ពី​ពីរ​នេះ ខ្ញុំ​បាន​ប្រើ​តែ​វា​បន្ថែម​ទៀត។

កំពុងដំណើរការសវនកម្មការហៅតាមប្រព័ន្ធ clock_settime и កំណត់ម៉ោងនៃថ្ងៃ ហើយព្យាយាមផ្លាស់ប្តូរកាលបរិច្ឆេទ៖

# 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 - ប៉ារ៉ាស៊ីតរបស់យើងត្រូវបានរកឃើញ។ ទោះបីជាមានឥរិយាបទ "ព្យាបាទ" របស់វាក៏ដោយ វាមិនអាចទៅរួចទេក្នុងការបដិសេធប្រព័ន្ធចូលប្រើតាមលក្ខខណ្ឌ ប៉ុន្តែខ្ញុំនៅតែចង់ដឹង អូសខេម, 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