งานเล็กๆ น้อยๆ นี้เกิดขึ้นในบ่ายวันศุกร์วันหนึ่ง และน่าจะใช้เวลา 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
ที่นี่ฉันจะทราบทันทีว่าเวลาของฮาร์ดแวร์นั้นถูกต้อง: จะง่ายกว่าในการนำทางต่อไป
นี่คือจุดเริ่มต้นของข้อผิดพลาดต่างๆ
ความผิดพลาดครั้งแรก ความมั่นใจในตนเอง
คลิก-แครก...
# 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 อ่านคนคนเดียวกัน และอธิบายกฎของฟอรัม/ไซต์อย่างแพร่หลาย แต่จะไม่ให้คำตอบแก่คุณ
ต่อไปนี้เป็นปัจจัยที่เป็นรูปธรรมบางประการ:
- ไม่มีใครนอกจากคุณสามารถรู้ปัญหาได้เช่นกัน
- ไม่มีใครสามารถทำการทดสอบภายใต้เงื่อนไขเดียวกันกับของคุณได้
และอัตนัย:
- คุณไม่สามารถให้ข้อมูลทั้งหมดสำหรับการแก้ปัญหาได้ เนื่องจากคุณได้มากับทิศทางที่ "ถูกต้อง" แล้วและกำลังนำเสนอแก่นแท้ของปัญหาโดยมุ่งเน้นไปที่ทิศทางนั้น
- หัวหน้าคนงาน (ผู้ดูแล, คนแก่, แอดมิน) ถูกเสมอ ถ้าหัวหน้าผิด...ก็รู้...
หากเมื่อตอบความคิดเห็น คุณยังคงอยู่ในขอบเขตของคำศัพท์ที่ถูกเซ็นเซอร์ แสดงว่าคุณมีความกังวลใจอย่างมาก
การตัดสิน
ไม่จำเป็นต้องแบ่งงานออกเป็นงานง่ายและซับซ้อน
เราหยุดพึ่งพาประสบการณ์ สถิติ ที่ปรึกษาของเรา และเริ่มไม่ "อธิบาย" ผลลัพธ์สุดท้าย แต่มองหาเหตุผลอย่างสม่ำเสมอ
เนื่องจากมีคนตั้งเวลา การเรียกของระบบจึงต้องเกิดขึ้น
เช่นเดียวกับในเอกสารประกอบซอฟต์แวร์ เอกสารที่ดีที่สุดคือแหล่งที่มา ดังนั้นในการบริหารระบบ ผู้ช่วยที่ดีที่สุดคือการตรวจสอบ ในกรณีของเรา ตรวจสอบ.
มีข้อสงสัยสักครู่.ฉันผ่านมานาไปแล้ว แต่ไม่แน่ใจทั้งหมดว่าสามารถตั้งเวลาใน Linux ได้เท่านั้น นาฬิกา_ตั้งเวลา и ตั้งเวลาของวันดังนั้นสำหรับการทดสอบครั้งแรก ฉันเลือกการโทรที่ "เหมาะสม" ทั้งหมด:
# 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, เวลา, 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หลังจากตรวจสอบให้แน่ใจว่าไม่มีบันทึกอื่นในตำแหน่งบันทึกที่ฉันสนใจ ซิสคอล นอกจากสองสิ่งนี้แล้ว ฉันยังใช้มันต่อไปเท่านั้น
เรียกใช้การตรวจสอบการโทรของระบบ นาฬิกา_ตั้งเวลา и ตั้งเวลาของวัน และลองเปลี่ยนวันที่:
# 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 - พบปรสิตของเราแล้ว แม้จะมีพฤติกรรม "ที่เป็นอันตราย" แต่ก็เป็นไปไม่ได้ที่จะปฏิเสธระบบการเข้าถึงแบบมีเงื่อนไข แต่ฉันก็ยังอยากจะรู้ ออสแคม, อะไรนะ?
พบคำตอบได้อย่างรวดเร็วใน :
#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");
}
ที่นี่จะดูน่ารักขนาดไหน แสดงความคิดเห็น เส้น คำเตือน...
ที่มา: will.com