Bu önemsiz görev bir Cuma öğleden sonra ortaya çıktı ve 2-3 dakika sürmesi gerekiyordu. Genel olarak, her zamanki gibi.
Bir meslektaşım benden kendi sunucusundaki betiği düzeltmemi istedi. Yaptım, ona verdim ve istemeden de olsa düşürdüm: "Zaman 5 dakika hızlı." Sunucunun senkronizasyonu kendisi yapmasına izin verin. Yarım saat, bir saat geçti ama o hâlâ şişiyor ve sessizce küfrediyordu.
"Aptal! — Sunucu konsoluna geçerken düşündüm — tamam, birkaç dakika daha ara vereceğim.
Bak ntp, rdate, sdwdate yüklü değil zaman senkronizasyonu devre dışı ve çalışmıyor.
# 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
Burada donanım zamanının doğru olduğunu hemen not edeceğim: daha ileri gitmek daha kolay olacak.
İşte bir dizi hata burada başladı.
İlk hata. Özgüven
Tıkır tıkır tık...
# 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
Her şey yolunda, zaman senkronize, sistem zamanı donanım saati ile eşleşiyor. "Al" dedim ve işime döndüm.
“Neyi almak? - meslektaşı öfkeliydi. "Aynı saat!"
Tipik problemleri çözdükçe, düşünceniz daha da körleşir ve artık yüzüncü veya bininci durumun farklı olacağını düşünmezsiniz, ama bu sefer değil.
# 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
Sistem saati yine yanlış.
Tekrar deneyelim:
# 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
Bunu farklı şekilde yapalım:
# 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
Ve böylece:
# 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
Zaman bir saniyeye ayarlanır ve hemen tekrar "acele etmeye" başlar.
Aynı zamanda loglarda böyle bir manuel değişiklik anında sadece saatin sırasıyla doğru/yanlış yönde değiştiğini ve ara sıra da sistem raporlarını görüyoruz. Yeniden senkronize ediliyor systemd-timesyncd'den.
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
burada
# ps afx | grep "[1]187"
1187 ? Ss 0:02 /lib/systemd/systemd --user
Bu noktada nedeni aramak zaten gerekliydi, ancak 18 yıllık yönetimden sonra beyin "zaman" hatalarına ilişkin istatistikler biriktirdi ve alışkanlıktan dolayı yine senkronizasyonu suçluyor.
Tamamen kapatalım.
# 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
ve günlüklerde
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
Yeniden senkronize ediliyor kaybolmuştur ve bunun dışında kütükler bozulmamıştır.
Sonuçların kontrol edilmesi tcp dökümü tüm arayüzlerde 123 numaralı bağlantı noktasında. Hiçbir istek yok ama zaman hâlâ akıp gidiyor.
İkinci hata. Acele etmek
Haftanın bitimine bir saat kaldı ve önemsiz bir çözülmemiş sorunla hafta sonuna gitmek istemiyorum (koddaki saate dikkat etmeyin, makale önümüzdeki günlerde yazılmıştır) ).
Ve burada yine sebebi aramak yerine sonuca bir açıklama getirmeye çalıştım. “İcat” diyorum çünkü sonuca ilişkin açıklama ne kadar mantıklı olursa olsun, sorunun çözümüne yönelik kusurlu bir yaklaşımdır.
Bu sunucu bir akış sunucusudur ve DVB-S2 akışını IP'ye dönüştürür. DVB-S akışı zaman damgaları içerir, bu nedenle alıcılar, çoklayıcılar, karıştırıcılar ve televizyonlar bunları sistem saatini senkronize etmek için sıklıkla kullanır. DVB-S kartı sürücüleri çekirdeğin içine yerleştirilmiştir, dolayısıyla DVB-S2 akışının kaldırıldığından emin olmanın en hızlı yolu "plakalardan" gelen kabloların bağlantısını kesmektir. Neyse ki sunucu duvarın arkasında, öyle olsun.
Elbette, eğer günlükler orada olması gerekenleri içerseydi, bu olmazdı, ancak yine de makalenin sonunda bununla ilgili daha fazla bilgi vereceğiz.
Zaten tüm uydu sinyallerini kaldırdığımız için karasal sinyalleri de kaldıracağız - aynı zamanda tüm ağ kablolarını da çıkarıyoruz. Sunucunun dış dünyayla bağlantısı kesilir ve tamamen otonom olarak çalışır ancak sistem saati hala acele halindedir.
Haftalık çalışma bitti ve tarih/saat meselesi kritik değil, o yüzden eve gidebilirsin ama burada yeni bir hata yapıyorum.
Üçüncü hata. Danışman
Asla! Cevabı Google'ın ilk sayfasını incelemekten ve tek bir man sayfasını okumaktan fazlasını gerektiriyorsa, asla forumlarda ve genel uzmanlaşmış (stackoverflow) sitelerde soru sormayın.
Sizi Google'a geri gönderecekler, aynı adamı okuyacaklar ve forumun/sitenin kurallarını popüler bir şekilde açıklayacaklar, ancak size bir cevap vermeyecekler.
İşte bazı nesnel faktörler:
- sorunu sizden başka kimse bilemez;
- hiç kimse sizinkiyle aynı koşullar altında test yapamaz
ve öznel:
- Sorunu çözmek için tüm girdileri veremeyebilirsiniz çünkü zaten "doğru" yönü buldunuz ve sorunun özünü ona odaklanarak sunuyorsunuz;
- ustabaşı (moderatör, eski zamanlayıcı, yönetici) her zaman haklıdır, eğer ustabaşı hatalıysa... yani, bilirsiniz...
Yorumlara yanıt verirken sansürlenen kelime dağarcığının sınırları dahilinde kaldıysanız, o zaman sinirleriniz güçlü demektir.
karar
Görevleri basit ve karmaşık olarak ayırmaya gerek yoktur.
Deneyimlerimize, istatistiklerimize, danışmanlarımıza güvenmeyi bırakırız ve nihai sonucu "açıklamaya" değil, sürekli olarak nedenini aramaya başlarız.
Birisi zamanı ayarladığı için ilgili sistem çağrısının gerçekleşmesi gerekir.
Yazılım dokümantasyonunda en iyi dokümanlar kaynaklar olduğu gibi, bizim durumumuzda sistem yönetiminde de en iyi yardımcı denetimdir. denetim.
Bir anlık şüpheManayı inceledim ama Linux'ta saatin yalnızca ayarlanabileceğinden tam olarak emin değildim saat_ayar zamanı и gün ayarı, bu nedenle ilk test için tüm "uygun" çağrıları seçtim:
# 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
ve atma s390_runtime_instr, zaman, timerfd_createhangi denetimctl bunu tanımadı, başlangıçta şu formda bir denetim başlattı:
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İlgilendiğim log konumlarında başka log olmadığından emin olduktan sonra sistem çağrıları Bu ikisinin yanı sıra sadece onları daha da kullandım.
Sistem çağrısı denetimi çalıştırma saat_ayar zamanı и gün ayarı ve tarihi değiştirmeyi deneyin:
# auditctl -a exit,always -S clock_settime -S settimeofday && date -s "2019-08-22 12:10:00" && sleep 5 && auditctl -D
Beş saniyelik bir gecikme eklenir, böylece "parazitimizin" zamanı düzeltmesi garanti edilir.
Rapora bakıyoruz:
# 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
Burada bizimkileri görüyoruz tarih ve bizim tarafımızdan bilinmiyor chkcache_processes. Yukarıdaki raporda yer aldı çünkü aureport ikiliden dönüştürme sırasında çıktıyı tarihe göre sıraladı ve olay bizim ayarladığımız zamanda gerçekleşti. tarih -s "2019-08-22 12:10:00".
Onu kim doğurdu?
# 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/yerel/bin/oscam - parazitimiz bulundu. “Kötü niyetli” davranışına rağmen koşullu erişim sistemini reddetmek imkansızdır ama yine de bilmek isterim oscam, O NE LAN?
Cevap hızlı bir şekilde bulunur :
#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");
}
Burada ne kadar tatlı görünüyor yorum yaptı astar uyarı...
Kaynak: habr.com