Tugas sing ora pati penting iki muncul ing sawijining dina Jumuah lan mesthine butuh wektu 2-3 menit. Umumé, kaya biasane.
A rowange takon kula kanggo ndandani script ing server kang. Aku nindakake, menehi dheweke lan ora sengaja nyelehake: "Wektu cepet 5 menit." Ayo server nangani sinkronisasi dhewe. Setengah jam, jam wis liwati, lan dheweke isih puffed lan meneng ipat-ipat.
“Bodho! - Aku mikir, ngalih menyang konsol server - oke, aku bakal ngaso sawetara menit maneh.
We katon ntp, rdate, sdwdate ora diinstal jancok dipatèni lan ora mlaku.
# 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
Ing kene aku bakal langsung nyathet yen wektu hardware wis bener: bakal luwih gampang navigasi.
Iki ngendi seri kesalahane wiwit.
Kesalahan pisanan. Rasa percaya diri
Klik-klik...
# 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
Kabeh apik, wektu disinkronake, wektu sistem cocog karo hardware. "Njupuk," ujarku lan bali menyang bisnisku.
“Njupuk apa? - rowange ana nesu. "Iku wektu sing padha!"
Luwih akeh sampeyan ngrampungake masalah sing khas, pikiran sampeyan bakal dadi blinker lan sampeyan ora mikir maneh yen kahanan satus utawa sewu bakal beda, nanging ora wektu iki.
# 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
Wektu sistem salah maneh.
Ayo coba maneh:
# 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
Ayo dadi beda:
# 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
Nanging kaya iki:
# 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
Wektu disetel kanggo pamisah detik, lan langsung wiwit "rush" maneh.
Ing wektu sing padha, ing log, nalika owah-owahan manual kasebut, kita mung ndeleng laporan sistem yen wektu wis diganti, ing arah sing bener / salah lan sok-sok. Nyinkronake maneh saka 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
kene
# ps afx | grep "[1]187"
1187 ? Ss 0:02 /lib/systemd/systemd --user
Ing jalur iki, iku wis perlu kanggo nggoleki alesan, nanging liwat 18 taun administrasi otak wis akumulasi statistik ing "wektu" kasalahan lan, metu saka pakulinan, maneh nyalahake sinkronisasi.
Ayo dipateni kabeh.
# 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
lan ing log
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
Nyinkronake maneh ilang lan digunakake log iku murni.
Priksa kesimpulan tcpdump ing port 123 ing kabeh antarmuka. Ora ana panjaluk, nanging wektu isih mlayu.
Kesalahan loro. Rush
Ana jam maneh nganti akhir minggu kerja, lan aku ora pengin mangkat ing akhir minggu kanthi masalah sing ora pati penting (ora nggatekake wektu ing kode, artikel kasebut ditulis ing dina sabanjure. ).
Lan ing kene maneh, tinimbang nggoleki alesan, aku wiwit nyoba kanggo nerangake asil. Aku ngomong "invent" amarga ora ketompo carane logis panjelasan kanggo asil bisa, iku pendekatan cacat kanggo mecahaken masalah.
Server iki minangka server streaming lan ngowahi stream DVB-S2 dadi IP. Stream DVB-S ngemot cap wektu, mula panrima, multiplexer, scrambler lan televisi asring digunakake kanggo nyinkronake jam sistem. Driver Papan DVB-S dibangun ing kernel, supaya cara paling cepet kanggo mesthekake yen stream DVB-S2 dibusak kanggo medhot kabel teka saka "piring". Begjanipun, server iku konco tembok, supaya dadi.
Mesthi, yen log wis ngemot apa sing kudu ana, iki ora bakal kelakon, nanging luwih akeh babagan, maneh, ing pungkasan artikel.
Ya, amarga kita wis ngilangi kabeh sinyal satelit, kita uga bakal mbusak sing terrestrial - ing wektu sing padha, kita narik kabeh kabel jaringan. Server dadi Cut mati saka donya njaba lan bisa rampung autonomously, nanging jam sistem isih cepet-cepet.
Minggu kerja wis rampung, lan masalah tanggal / wektu dhewe ora kritis, mula sampeyan bisa mulih, nanging ing kene aku nggawe kesalahan anyar.
Kesalahan telu. Penasehat
ora tau! Aja takon pitakonan ing forum lan situs khusus umum (a la stackoverflow) yen jawaban mbutuhake luwih saka sinau kaca pisanan Google lan maca siji kaca wong.
Dheweke bakal ngirim sampeyan bali menyang Google, maca wong sing padha lan umume nerangake aturan forum / situs, nanging ora bakal menehi jawaban.
Ing ngisor iki sawetara faktor objektif:
- ora ana siji kajaba sampeyan bisa ngerti masalah uga;
- ora ana sing bisa nindakake tes ing kahanan sing padha karo sampeyan
lan subyektif:
- sampeyan bisa uga ora menehi kabeh input kanggo ngrampungake masalah, amarga sampeyan wis teka munggah karo "tengen" arah lan presenting inti saka masalah fokus ing;
- mandor (moderator, old-timer, admin) mesthi bener, yen mandor salah ...
Yen, nalika mbales komentar, sampeyan tetep ana ing watesan kosakata sing disensor, mula sampeyan duwe saraf sing kuwat.
kaputusan
Ora perlu mbagi tugas dadi prasaja lan rumit.
Kita mandheg ngandelake pengalaman, statistik, penasihat lan wiwit ora "nerangake" asil pungkasan, nanging terus-terusan golek alesan.
Amarga ana wong sing nyetel wektu, telpon sistem sing cocog kudu kedadeyan.
Kaya ing dokumentasi piranti lunak, dokumen paling apik minangka sumber, mula ing administrasi sistem, asisten paling apik yaiku audit, ing kasus kita auditd.
Sedhela mangu-manguAku lunga liwat mana, nanging ora tanggung manawa wektu ing Linux mung bisa disetel clock_settime и settimeofday, dadi kanggo tes pisanan aku milih kabeh panggilan "cocok":
# 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
lan mbuwang s390_runtime_instr, stime, timerfd_create, kang auditctl ora ngerti, wiwitane ngluncurake audit ing wangun:
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 utimesSawise nggawe manawa ora ana log liyane ing lokasi log sing dakkarepake syscalls Kejabi loro iki, aku mung digunakake luwih.
Nglakokake audit panggilan sistem clock_settime и settimeofday lan nyoba ngganti tanggal:
# auditctl -a exit,always -S clock_settime -S settimeofday && date -s "2019-08-22 12:10:00" && sleep 5 && auditctl -D
Wektu tundha limang detik ditambahake supaya "parasit" kita dijamin mbenerake wektu kasebut.
Ayo ndeleng laporan:
# 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
Kene kita ndeleng kita tanggal lan ora dingerteni kanggo kita chkcache_processes. Iki rampung ing laporan ing ndhuwur amarga aureport ngurutake output miturut tanggal nalika ngowahi saka binar, lan acara kasebut kedadeyan nalika kita nyetel tanggal -s "2019-08-22 12:10:00".
Sapa sing nglairake dheweke?
# 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 - parasit kita wis ditemokake. Senadyan prilaku "angkoro", iku mokal kanggo nolak sistem akses kondisional, nanging aku isih pengin ngerti oscam, WTF?
Jawaban cepet ditemokake ing :
#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");
}
Carane cute katon kene komentar metu baris bebaya...
Source: www.habr.com