Tugas sepele ini muncul pada salah satu hari Jumat dan seharusnya memakan waktu 2-3 menit. Secara umum, seperti biasa.
Seorang kolega meminta saya untuk memperbaiki skrip di servernya. Dia melakukannya, menyerahkannya kepadanya dan menjatuhkannya secara tidak sengaja: "Waktu terburu-buru selama 5 menit." Servernya, bahkan jika dia mengerti sinkronisasi. Setengah jam, satu jam telah berlalu, dan dia mengisap dan diam-diam bersumpah.
"Kekacauan! - Saya pikir, beralih ke konsol server - yah, saya akan keluar selama beberapa menit. "
Kami melihat,
ntp, rdate, sdwdate tidak diinstal,
timesyncd dinonaktifkan dan tidak berjalan.
# 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
Di sini saya segera mencatat bahwa waktu perangkat keras sudah benar: akan lebih mudah untuk menavigasi lebih jauh.
Dari sini serangkaian kesalahan dimulai.
Kesalahan pertama. Kepercayaan diri
Klats-klats ...
# 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
Semuanya baik-baik saja, waktu disinkronkan, sistem bertepatan dengan perangkat keras. "Ambillah," aku menjatuhkan, dan kembali ke bisnisku.
"Apa yang diambil?" - kolega itu marah. "Masa lalu!"
Semakin Anda menyelesaikan masalah-masalah tipikal, semakin banyak pemikiran Anda mulai dan Anda tidak berpikir bahwa situasi keseratus atau keseribu akan berbeda, tetapi tidak kali ini.
# 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
Waktu sistem kembali salah.
Mari kita coba lagi:
# 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
Mari kita lakukan secara berbeda:
# 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
Jadi:
# 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
Waktu diatur untuk sepersekian detik, dan kemudian mulai "terburu-buru" lagi.
Pada saat yang sama, dalam log, pada saat perubahan manual seperti itu, kami hanya melihat sistem melaporkan bahwa waktu telah berubah, masing-masing, dalam arah yang benar / salah dan kadang-kadang melakukan Sinkronisasi
ulang dari 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
disini
# ps afx | grep "[1]187" 1187 ? Ss 0:02 /lib/systemd/systemd --user
Pada titik ini, sudah perlu untuk mencari penyebabnya, tetapi otak selama 18 tahun administrasi telah mengembangkan statistik kesalahan "waktu" dan karena kebiasaan lagi menyalahkan sinkronisasi.
Matikan sepenuhnya.
# 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
dan dalam 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
Penyinkronan ulang hilang dan sisa log masih asli.
Kami memeriksa output
tcpdump pada port 123 pada semua antarmuka. Tidak ada permintaan, tetapi waktu juga berjalan.
Kesalahan kedua. Tergesa-gesa
Ada satu jam tersisa sampai akhir minggu kerja, tetapi Anda tidak ingin pergi untuk akhir pekan dengan tugas yang buruk (tidak memperhatikan waktu dalam kode, artikel itu ditulis pada hari-hari berikutnya).
Dan di sini lagi, alih-alih mencari alasan, saya mulai mencoba memberikan penjelasan untuk hasilnya. Saya mengatakan "menciptakan", karena tidak peduli seberapa logis penjelasan untuk hasilnya, ini adalah pendekatan yang salah untuk menyelesaikan masalah.
Server ini streaming dan mengubah aliran DVB-S2 ke IP. Ada cap waktu dalam aliran DVB-S, sehingga penerima, multiplekser, pengacak, dan televisi sering menggunakannya untuk menyinkronkan jam sistem. Driver untuk papan DVB-S dikompilasi ke dalam kernel, sehingga cara tercepat untuk menjamin aliran DVB-S2 yang bersih adalah dengan mencabut kabel yang datang dari "pelat". Untungnya, server ada di belakang tembok, oleh karena itu, biarlah.
Tentu saja, jika log memiliki apa yang seharusnya ada di sana, ini tidak akan terjadi, tetapi lebih dari itu, sekali lagi, di akhir artikel.
Nah, karena kami telah menghapus semua sinyal satelit, kami juga akan menghapus yang terestrial - di sepanjang jalan kami mencabut semua kabel jaringan. Server menjadi terputus dari dunia luar dan bekerja sepenuhnya secara mandiri, tetapi jam sistem masih terburu-buru.
Minggu kerja sudah berakhir, dan pertanyaan tentang tanggal / waktu tidak kritis, jadi Anda bisa pulang, tapi di sini saya membuat kesalahan baru.
Kesalahan ketiga. Penasehat
Tidak pernah! Jangan pernah mengajukan pertanyaan di forum dan situs-situs yang umumnya terspesialisasi (a la stackoverflow) jika jawabannya membutuhkan lebih dari mempelajari penerbitan halaman pertama Google dan membaca satu halaman man'a.
Anda akan dikirim kembali ke google, membaca orang yang sama dan menjelaskan aturan forum / situs secara populer, tetapi tidak akan memberikan jawaban.
Ada dua faktor obyektif:
- tidak seorang pun kecuali Anda dapat mengetahui masalahnya juga;
- tidak ada yang bisa menguji dalam kondisi yang sama seperti Anda
dan subyektif:
- Anda mungkin tidak memberikan semua input untuk menyelesaikan masalah, karena Anda telah menemukan arah yang "benar" dan menyatakan esensi masalah dengan bertumpu pada itu;
- mandor (moderator, old-timer, admin) selalu benar jika mandor salah ... yah, Anda tahu ...
Jika sebagai tanggapan atas komentar Anda tetap dalam kerangka kosa kata sensor, maka Anda memiliki keberanian yang kuat.
Solusi
Tidak perlu lagi membagi tugas menjadi sederhana dan kompleks.
Kami berhenti mengandalkan pengalaman, statistik, penasihat kami, dan mulai tidak "menjelaskan" hasil akhir, tetapi untuk secara konsisten mencari alasannya.
Setelah seseorang mengatur waktu, maka panggilan sistem yang tepat harus terjadi.
Seperti dalam dokumentasi perangkat lunak, dok terbaik adalah sumber, jadi dalam administrasi sistem, asisten terbaik adalah audit, dalam audit kasus kami.
Momen keraguanSaya menjalankan mans, tetapi tidak sepenuhnya yakin bahwa jam di Linux hanya dapat diatur oleh
clock_settime dan
settimeofday , jadi untuk tes pertama saya memilih semua 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
dan membuang
s390_runtime_instr, stime, timerfd_create , yang
auditctl tidak kenali, awalnya memulai audit dalam bentuk:
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
Setelah memastikan bahwa di tempat-tempat log yang menarik minat saya, tidak ada
syscall lain selain keduanya, saya hanya menggunakannya.
Kami memulai audit panggilan sistem
clock_settime dan
settimeofday dan mencoba mengubah tanggal:
# auditctl -a exit,always -S clock_settime -S settimeofday && date -s "2019-08-22 12:10:00" && sleep 5 && auditctl -D
Penundaan lima detik telah ditambahkan sehingga "parasit" kami dijamin untuk memperbaiki waktu.
Kami melihat 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
Di sini kita melihat
tanggal kami dan tidak diketahui oleh kami
chkcache_proces . Ternyata dalam laporan di atas, karena aureport mengurutkan output berdasarkan tanggal ketika mengkonversi dari tampilan biner, dan peristiwa itu terjadi pada saat kita mengatur
tanggal -s "2019-08-22 12:10:00" .
Siapa yang melahirkannya?
# 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 kami ditemukan. Terlepas dari perilakunya yang "jahat", tidak mungkin untuk meninggalkan sistem akses bersyarat, tapi tetap saya ingin tahu,
oscam , WTF?
Jawabannya cepat ditemukan di
sumber :
#if defined(CLOCKFIX) if (tv.tv_sec > lasttime.tv_sec || (tv.tv_sec == lasttime.tv_sec && tv.tv_usec >= lasttime.tv_usec))
Betapa
bagusnya garis
peringatan yang dikomentari terlihat di sini ...