Nhiệm vụ tầm thường này phát sinh vào một chiều thứ Sáu và lẽ ra phải mất 2-3 phút. Nói chung, như mọi khi.
Một đồng nghiệp đã yêu cầu tôi sửa tập lệnh trên máy chủ của anh ấy. Tôi làm theo, đưa cho anh và vô tình đánh rơi: “Thời gian trôi qua nhanh 5 phút”. Hãy để máy chủ tự xử lý việc đồng bộ hóa. Nửa giờ, một giờ trôi qua, hắn vẫn thở hổn hển, thầm mắng.
"Ngốc nghếch! — Tôi nghĩ, chuyển sang bảng điều khiển máy chủ — được rồi, tôi sẽ nghỉ ngơi thêm vài phút nữa.”
Chúng ta nhìn ntp, rdate, sdwdate chưa cài đặt đồng bộ hóa thời gian bị vô hiệu hóa và không chạy.
# 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
Ở đây tôi sẽ lưu ý ngay rằng thời gian phần cứng là chính xác: việc điều hướng xa hơn sẽ dễ dàng hơn.
Đây là nơi bắt đầu hàng loạt sai lầm.
Sai lầm đầu tiên. Tự tin
Lạch cạch...
# 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
Mọi thứ đều ổn, thời gian đồng bộ, thời gian hệ thống khớp với phần cứng. “Cầm lấy đi,” tôi nói và quay lại công việc của mình.
"Lấy cái gì? - đồng nghiệp phẫn nộ. "Đó là cùng một lúc!"
Càng giải quyết nhiều vấn đề điển hình, suy nghĩ của bạn càng trở nên mù quáng và bạn không còn nghĩ rằng tình huống thứ một trăm hay thứ nghìn sẽ khác, nhưng lần này thì không.
# 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
Giờ hệ thống lại sai nữa.
Hãy thử lại lần 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
Hãy làm theo cách khác:
# 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
Nhưng như thế này:
# 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
Thời gian được ấn định trong tích tắc và ngay lập tức lại bắt đầu “vội vàng”.
Đồng thời, trong nhật ký, tại thời điểm thay đổi thủ công như vậy, chúng tôi chỉ thấy hệ thống báo cáo rằng thời gian đã thay đổi tương ứng theo hướng đúng/sai và đôi khi Đang đồng bộ lại từ 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
đây
# ps afx | grep "[1]187"
1187 ? Ss 0:02 /lib/systemd/systemd --user
Đến lúc này, cần phải tìm nguyên nhân, nhưng qua 18 năm quản lý, bộ não đã tích lũy số liệu thống kê về các lỗi “thời gian” và theo thói quen, lại đổ lỗi cho sự đồng bộ hóa.
Hãy tắt nó hoàn toàn.
# 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
và trong nhật ký
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
Đang đồng bộ lại biến mất và nếu không thì các bản ghi vẫn còn nguyên vẹn.
Kiểm tra kết luận tcpdump trên cổng 123 trên tất cả các giao diện. Không có yêu cầu nào, nhưng thời gian vẫn đang trôi đi.
Lỗi thứ hai. Cây bấc
Còn một tiếng nữa là hết tuần làm việc, và tôi không muốn phải nghỉ cuối tuần với một vấn đề tầm thường chưa được giải quyết (đừng chú ý đến thời gian trong code, bài viết được viết vào những ngày tiếp theo) ).
Và ở đây một lần nữa, thay vì tìm kiếm lý do, tôi bắt đầu cố gắng đưa ra lời giải thích cho kết quả. Tôi nói “phát minh” bởi vì cho dù lời giải thích cho kết quả có hợp lý đến đâu thì đó vẫn là một cách tiếp cận thiếu sót để giải quyết vấn đề.
Máy chủ này là máy chủ phát trực tuyến và chuyển đổi luồng DVB-S2 thành IP. Dòng DVB-S chứa các nhãn thời gian nên các bộ thu, bộ ghép kênh, bộ mã hóa và TV thường sử dụng chúng để đồng bộ đồng hồ hệ thống. Trình điều khiển bo mạch DVB-S được tích hợp sẵn trong kernel, vì vậy cách nhanh nhất để đảm bảo luồng DVB-S2 bị loại bỏ là ngắt kết nối các dây cáp đến từ các “tấm”. May mắn thay, máy chủ ở phía sau bức tường, vậy thôi.
Tất nhiên, nếu nhật ký chứa những gì đáng lẽ phải có ở đó thì điều này đã không xảy ra, nhưng một lần nữa, hãy nói thêm về điều đó ở cuối bài viết.
Chà, vì chúng tôi đã loại bỏ tất cả các tín hiệu vệ tinh nên chúng tôi cũng sẽ loại bỏ các tín hiệu trên mặt đất - đồng thời chúng tôi rút tất cả các dây cáp mạng. Máy chủ bị cắt khỏi thế giới bên ngoài và hoạt động hoàn toàn tự động, nhưng đồng hồ hệ thống vẫn chạy nhanh.
Tuần làm việc đã kết thúc và bản thân vấn đề ngày/giờ không quan trọng nên bạn có thể về nhà, nhưng ở đây tôi lại mắc một lỗi mới.
Lỗi thứ ba. cố vấn
Không bao giờ! Không bao giờ đặt câu hỏi trên các diễn đàn và các trang web chuyên biệt chung (a la stackoverflow) nếu câu trả lời cho nó đòi hỏi nhiều hơn việc nghiên cứu trang đầu tiên của Google và đọc một trang man.
Họ sẽ gửi bạn trở lại Google, đọc cùng một người đàn ông và giải thích một cách phổ biến các quy tắc của diễn đàn/trang web, nhưng sẽ không cho bạn câu trả lời.
Sau đây là một số yếu tố khách quan:
- không ai ngoại trừ bạn có thể biết được vấn đề;
- không ai có thể tiến hành kiểm tra trong điều kiện giống như của bạn
và chủ quan:
- bạn có thể không đưa ra tất cả thông tin đầu vào để giải quyết vấn đề, bởi vì bạn đã đưa ra hướng “đúng” và đang trình bày bản chất của vấn đề tập trung vào nó;
- quản đốc (người điều hành, người cũ, quản trị viên) luôn đúng, nếu quản đốc sai... à, bạn biết đấy...
Nếu khi trả lời bình luận mà bạn vẫn nằm trong giới hạn từ vựng bị kiểm duyệt thì bạn có thần kinh rất mạnh.
phán quyết
Không cần thiết phải chia nhiệm vụ thành đơn giản và phức tạp.
Chúng tôi ngừng dựa vào kinh nghiệm, số liệu thống kê, cố vấn của mình và bắt đầu không “giải thích” kết quả cuối cùng mà liên tục tìm kiếm lý do.
Vì ai đó đặt thời gian nên cuộc gọi hệ thống tương ứng phải xảy ra.
Giống như trong tài liệu phần mềm, tài liệu tốt nhất là nguồn, vì vậy trong quản trị hệ thống, trợ lý tốt nhất là kiểm toán, trong trường hợp của chúng tôi. đã kiểm toán.
Một khoảnh khắc nghi ngờTôi đã xem qua mana, nhưng không hoàn toàn chắc chắn rằng thời gian trong Linux chỉ có thể được đặt đồng hồ_settime и thời gian trong ngày, vì vậy trong lần thử nghiệm đầu tiên, tôi đã chọn tất cả các lệnh gọi “phù hợp”:
# 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
và loại bỏ s390_runtime_instr, stime, timerfd_create, cái mà kiểm toán đã không nhận ra nó, ban đầu đã tiến hành kiểm toán theo hình thức:
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 utimesSau khi đảm bảo rằng không có nhật ký nào khác ở vị trí nhật ký mà tôi quan tâm tòa nhà chọc trời Ngoài hai cái này, tôi chỉ sử dụng chúng thêm.
Chạy kiểm tra cuộc gọi hệ thống đồng hồ_settime и thời gian trong ngày và cố gắng thay đổi ngày:
# auditctl -a exit,always -S clock_settime -S settimeofday && date -s "2019-08-22 12:10:00" && sleep 5 && auditctl -D
Độ trễ năm giây được thêm vào để "ký sinh trùng" của chúng tôi được đảm bảo điều chỉnh thời gian.
Hãy xem báo cáo:
# 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
Ở đây chúng tôi thấy ngày và chúng tôi chưa biết chkcache_processes. Nó kết thúc trong báo cáo ở trên vì aureport đã sắp xếp đầu ra theo ngày khi chuyển đổi từ nhị phân và sự kiện xảy ra tại thời điểm chúng tôi đặt ngày -s "2019-08-22 12:10:00".
Ai đã sinh ra anh ta?
# 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 - ký sinh trùng của chúng tôi đã được tìm thấy. Bất chấp hành vi “độc hại” của nó, không thể từ chối hệ thống truy cập có điều kiện, nhưng tôi vẫn muốn biết ocam, WTF?
Câu trả lời nhanh chóng được tìm thấy trong :
#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");
}
Ở đây trông dễ thương làm sao Bình luận đường kẻ cảnh báo...
Nguồn: www.habr.com