ວຽກງານທີ່ງ່າຍກວ່າ, ຂ້ອຍມັກຈະເຮັດຜິດ

ວຽກງານເລັກນ້ອຍນີ້ເກີດຂຶ້ນໃນຕອນບ່າຍວັນສຸກມື້ຫນຶ່ງແລະຄວນຈະໃຊ້ເວລາ 2-3 ນາທີ. ໂດຍທົ່ວໄປ, ຕາມສະເຫມີ.

ເພື່ອນຮ່ວມງານໄດ້ຂໍໃຫ້ຂ້ອຍແກ້ໄຂສະຄິບໃນເຄື່ອງແມ່ຂ່າຍຂອງລາວ. ຂ້າພະເຈົ້າໄດ້ເຮັດມັນ, ຍື່ນໃຫ້ລາວແລະຫຼຸດລົງໂດຍບໍ່ໄດ້ຕັ້ງໃຈ: "ເວລາແມ່ນໄວ 5 ນາທີ." ໃຫ້ເຄື່ອງແມ່ຂ່າຍຈັດການ synchronization ຕົວຂອງມັນເອງ. ເຄິ່ງ​ຊົ່ວ​ໂມງ​ໜຶ່ງ​ຊົ່ວ​ໂມງ​ຜ່ານ​ໄປ, ລາວ​ກໍ​ຍັງ​ບ້າ​ປາກ​ແລະ​ດ່າ​ຢ່າງ​ງຽບໆ.

“ໂງ່! — ຂ້າ​ພະ​ເຈົ້າ​ຄິດ​ວ່າ, ສະ​ຫຼັບ​ກັບ server console — ບໍ່​ເປັນ​ຫຍັງ, ຂ້າ​ພະ​ເຈົ້າ​ຈະ​ພັກ​ຜ່ອນ​ສໍາ​ລັບ​ສອງ​ສາມ​ນາ​ທີ​ຫຼາຍ.”

ໃຫ້ເຮົາເບິ່ງ 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

ທຸກຢ່າງແມ່ນດີ, ເວລາຖືກ synchronized, ເວລາຂອງລະບົບກົງກັບຮາດແວ. "ເອົາມັນ," ຂ້ອຍເວົ້າແລະກັບຄືນໄປຫາທຸລະກິດຂອງຂ້ອຍ.

“ເອົາຫຍັງ? - ເພື່ອນຮ່ວມງານແມ່ນ indignant. "ມັນ​ເປັນ​ເວ​ລາ​ດຽວ​ກັນ!"

ຍິ່ງເຈົ້າແກ້ໄຂບັນຫາແບບປົກກະຕິຫຼາຍເທົ່າໃດ, ຄວາມຄິດຂອງເຈົ້າກໍ່ຍິ່ງກະພິບ ແລະເຈົ້າບໍ່ຄິດວ່າສະຖານະການຮ້ອຍຫຼືພັນຈະແຕກຕ່າງກັນ, ແຕ່ບໍ່ແມ່ນເທື່ອນີ້.

# 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 ປີຂອງການບໍລິຫານ, ສະຫມອງໄດ້ສະສົມສະຖິຕິກ່ຽວກັບຄວາມຜິດພາດ "ເວລາ" ແລະ, ອອກຈາກນິໄສ, ອີກເທື່ອຫນຶ່ງ, ໂທດ synchronization.
ໃຫ້ປິດມັນຢ່າງສົມບູນ.

# 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

ກຳລັງຊິ້ງຂໍ້ມູນຄືນໃໝ່ ຫາຍ​ໄປ​ແລະ​ບໍ່​ດັ່ງ​ນັ້ນ​ໄມ້​ທ່ອນ​ແມ່ນ pristine​.

ການກວດສອບບົດສະຫຼຸບ tcpdump ໃນພອດ 123 ໃນທຸກສ່ວນຕິດຕໍ່. ບໍ່ມີການຮ້ອງຂໍ, ແຕ່ເວລາຍັງແລ່ນຫນີ.

ຄວາມຜິດພາດສອງ. ຟ້າວ

ຍັງມີເວລາ 1 ຊົ່ວໂມງຈົນຮອດທ້າຍອາທິດຂອງການເຮັດວຽກ, ແລະຂ້ອຍບໍ່ຢາກອອກໄປໃນທ້າຍອາທິດດ້ວຍບັນຫາທີ່ບໍ່ສາມາດແກ້ໄຂໄດ້ (ຢ່າເອົາໃຈໃສ່ກັບເວລາໃນລະຫັດ, ບົດຄວາມຖືກຂຽນໃນມື້ຕໍ່ມາ. ).
ແລະທີ່ນີ້ອີກເທື່ອຫນຶ່ງ, ແທນທີ່ຈະຊອກຫາເຫດຜົນ, ຂ້າພະເຈົ້າໄດ້ເລີ່ມຕົ້ນທີ່ຈະພະຍາຍາມຫາຄໍາອະທິບາຍສໍາລັບຜົນໄດ້ຮັບ. ຂ້າພະເຈົ້າເວົ້າວ່າ "ປະດິດ" ເພາະວ່າບໍ່ວ່າຄໍາອະທິບາຍສໍາລັບຜົນໄດ້ຮັບອາດຈະເປັນເຫດຜົນແນວໃດ, ມັນແມ່ນວິທີການທີ່ຜິດພາດໃນການແກ້ໄຂບັນຫາ.

ເຊີບເວີນີ້ເປັນເຊີບເວີສະຕີມ ແລະປ່ຽນການຖ່າຍທອດ DVB-S2 ເປັນ IP. ກະແສ DVB-S ປະກອບມີເວລາ, ດັ່ງນັ້ນເຄື່ອງຮັບ, multiplexers, scramblers ແລະໂທລະທັດມັກຈະໃຊ້ພວກມັນເພື່ອ synchronize ໂມງຂອງລະບົບ. ໄດເວີຂອງກະດານ DVB-S ຖືກສ້າງຂຶ້ນໃນແກ່ນ, ດັ່ງນັ້ນວິທີທີ່ໄວທີ່ສຸດເພື່ອຮັບປະກັນວ່າສາຍ DVB-S2 ຖືກໂຍກຍ້າຍແມ່ນເພື່ອຕັດສາຍທີ່ມາຈາກ "ແຜ່ນ". ໂຊກດີ, ເຄື່ອງແມ່ຂ່າຍແມ່ນຢູ່ຫລັງກໍາແພງ, ດັ່ງນັ້ນຈະເປັນມັນ.

ແນ່ນອນ, ຖ້າບັນທຶກມີສິ່ງທີ່ຄວນຈະມີ, ນີ້ຈະບໍ່ເກີດຂຶ້ນ, ແຕ່ເພີ່ມເຕີມກ່ຽວກັບວ່າ, ອີກເທື່ອຫນຶ່ງ, ໃນຕອນທ້າຍຂອງບົດຄວາມ.

ດີ, ນັບຕັ້ງແຕ່ພວກເຮົາໄດ້ເອົາສັນຍານດາວທຽມທັງຫມົດອອກແລ້ວ, ພວກເຮົາຍັງຈະເອົາສັນຍານດາວທຽມ - ໃນເວລາດຽວກັນພວກເຮົາດຶງສາຍເຄເບີນທັງຫມົດອອກ. ເຊີບເວີຖືກຕັດອອກຈາກໂລກພາຍນອກ ແລະເຮັດວຽກແບບອັດຕະໂນມັດຢ່າງສົມບູນ, ແຕ່ໂມງລະບົບຍັງຢູ່ໃນໄວ.

ອາທິດການເຮັດວຽກສິ້ນສຸດລົງ, ແລະບັນຫາວັນທີ / ເວລາຂອງມັນເອງບໍ່ສໍາຄັນ, ດັ່ງນັ້ນເຈົ້າສາມາດກັບບ້ານໄດ້, ແຕ່ຂ້ອຍເຮັດຜິດພາດໃຫມ່.

ຄວາມຜິດພາດສາມ. ທີ່ປຶກສາ

ບໍ່ເຄີຍ! ຢ່າຖາມຄໍາຖາມກ່ຽວກັບເວທີສົນທະນາແລະສະຖານທີ່ພິເສດທົ່ວໄປ (a la stackoverflow) ຖ້າຄໍາຕອບຂອງມັນຕ້ອງການຫຼາຍກວ່າການສຶກສາຫນ້າທໍາອິດຂອງ Google ແລະອ່ານຫນຶ່ງຫນ້າຜູ້ຊາຍ.

ພວກເຂົາຈະສົ່ງທ່ານກັບຄືນໄປຫາ Google, ອ່ານຜູ້ຊາຍຄົນດຽວກັນແລະມັກອະທິບາຍກົດລະບຽບຂອງເວທີ / ເວັບໄຊທ໌, ແຕ່ຈະບໍ່ໃຫ້ຄໍາຕອບ.

ນີ້ແມ່ນບາງປັດໃຈຈຸດປະສົງ:

• ບໍ່ມີໃຜຍົກເວັ້ນທ່ານສາມາດຮູ້ບັນຫາເຊັ່ນດຽວກັນ;
• ບໍ່ມີໃຜສາມາດດໍາເນີນການທົດສອບພາຍໃຕ້ເງື່ອນໄຂດຽວກັນກັບເຈົ້າ

ແລະຫົວຂໍ້:

• ທ່ານອາດຈະບໍ່ໃຫ້ຂໍ້ມູນທັງຫມົດສໍາລັບການແກ້ໄຂບັນຫາ, ເພາະວ່າທ່ານໄດ້ມາກັບທິດທາງ "ທີ່ຖືກຕ້ອງ" ແລະນໍາສະເຫນີຄວາມສໍາຄັນຂອງບັນຫາທີ່ສຸມໃສ່ມັນ;
• foreman (ຜູ້ຄວບຄຸມ, timer, old-timer, admin) ແມ່ນສະເຫມີ, ຖ້າ foreman ຜິດ ... , ເຈົ້າຮູ້ ...

ຖ້າ ຫາກ ວ່າ, ໃນ ເວ ລາ ທີ່ ຕອບ ກັບ ຄໍາ ເຫັນ, ທ່ານ ຍັງ ຢູ່ ໃນ ຂອບ ເຂດ ຈໍາ ກັດ ຂອງ ຄໍາ ສັບ censored, ຫຼັງ ຈາກ ນັ້ນ ທ່ານ ມີ ເສັ້ນ ປະ ສາດ ທີ່ ເຂັ້ມ ແຂງ.

ການຕັດສິນໃຈ

ບໍ່ຈໍາເປັນຕ້ອງແບ່ງວຽກອອກເປັນງ່າຍດາຍແລະສະລັບສັບຊ້ອນ.

ພວກເຮົາຢຸດເຊົາການອີງໃສ່ປະສົບການຂອງພວກເຮົາ, ສະຖິຕິ, ທີ່ປຶກສາແລະເລີ່ມຕົ້ນທີ່ຈະບໍ່ "ອະທິບາຍ" ຜົນໄດ້ຮັບສຸດທ້າຍ, ແຕ່ຊອກຫາເຫດຜົນຢ່າງຕໍ່ເນື່ອງ.

ນັບຕັ້ງແຕ່ຜູ້ໃດຜູ້ຫນຶ່ງກໍານົດເວລາ, ການໂທລະບົບທີ່ສອດຄ້ອງກັນຕ້ອງເກີດຂຶ້ນ.

ຄືກັນກັບໃນເອກະສານຊອບແວເອກະສານທີ່ດີທີ່ສຸດແມ່ນແຫຼ່ງ, ສະນັ້ນໃນການຄຸ້ມຄອງລະບົບ, ຜູ້ຊ່ວຍທີ່ດີທີ່ສຸດແມ່ນການກວດສອບ, ໃນກໍລະນີຂອງພວກເຮົາ. ການກວດສອບ.

ປັດ​ຈຸ​ບັນ​ຂອງ​ຄວາມ​ສົງ​ໃສ​ຂ້າພະເຈົ້າໄດ້ຜ່ານ mana, ແຕ່ບໍ່ແນ່ໃຈວ່າທັງຫມົດສາມາດກໍານົດເວລາໃນ Linux ເທົ່ານັ້ນ 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 ຈັດຮຽງຜົນຜະລິດຕາມວັນທີໃນເວລາທີ່ປ່ຽນຈາກຖານສອງ, ແລະເຫດການເກີດຂຶ້ນໃນເວລາທີ່ພວກເຮົາກໍານົດ. ວັນທີ "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