Энэ өчүүхэн ажил Баасан гарагийн үдээс хойш гарсан бөгөөд 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 урсгалыг арилгах хамгийн хурдан арга бол "хавтан" -аас ирж буй кабелийг салгах явдал юм. Аз болоход сервер нь хананы ард байгаа тул тийм байх ёстой.
Мэдээжийн хэрэг, бүртгэлүүд нь тэнд байх ёстой зүйлийг агуулсан байсан бол ийм зүйл тохиолдохгүй байх байсан, гэхдээ энэ талаар өгүүллийн төгсгөлд дахин хэлье.
За, бид хиймэл дагуулын бүх дохиог аль хэдийн устгасан тул хуурай газрын дохиог ч бас устгах болно - тэр үед бид бүх сүлжээний кабелийг татаж авдаг. Сервер нь гадаад ертөнцөөс тасарч, бүрэн бие даасан байдлаар ажилладаг боловч системийн цаг нь яарсан хэвээр байна.
Ажлын долоо хоног дуусч, огноо/цагийн асуудал өөрөө тийм ч чухал биш тул та зүгээр л гэртээ харьж болно, гэхдээ энд би шинэ алдаа гаргаж байна.
Алдаа гурав. Зөвлөхүүд
Хэзээ ч үгүй! Хэрэв хариулт нь Google-ийн эхний хуудсыг судалж, нэг хүний хуудас уншихаас илүү шаардлагатай бол форум болон ерөнхий тусгай (a la stackoverflow) сайтууд дээр асуулт бүү асуу.
Тэд таныг Google рүү буцааж илгээж, ижил хүнийг уншиж, форум/сайтын дүрмийг олон нийтэд тайлбарлах боловч танд хариу өгөхгүй.
Зарим объектив хүчин зүйлүүд энд байна:
- чамаас өөр хэн ч асуудлыг мэдэж чадахгүй;
- хэн ч тантай ижил нөхцөлд шалгалт хийж чадахгүй
ба субъектив:
- Та асуудлыг шийдэхийн тулд бүх саналаа өгөхгүй байж магадгүй, учир нь та аль хэдийн "зөв" чиглэлийг гаргаж ирсэн бөгөөд үүнд анхаарлаа хандуулж буй асуудлын мөн чанарыг танилцуулж байна;
- мастер (зохицуулагч, хуучин, админ) үргэлж зөв байдаг, хэрэв мастер буруу байвал ... за чи мэднэ ...
Хэрэв та сэтгэгдэлд хариулахдаа цензуртай үгсийн сангийн хязгаарт үлдсэн бол та хүчтэй мэдрэлтэй байна.
шийдвэр
Даалгавруудыг энгийн, төвөгтэй гэж хуваах шаардлагагүй.
Бид туршлага, статистик, зөвлөхдөө найдахаа больж, эцсийн үр дүнг "тайлбарлах" бус харин шалтгааныг байнга хайж эхэлдэг.
Хэн нэгэн цагийг тохируулсан тул холбогдох системийн дуудлага хийх ёстой.
Програм хангамжийн баримт бичигт хамгийн сайн баримт бичиг нь эх сурвалж байдагтай адил системийн удирдлагад хамгийн сайн туслах нь аудит байдаг. аудитд.
Эргэлзээтэй мөчБи манатай танилцсан боловч Линукс дээрх цагийг зөвхөн тохируулж болно гэдэгт бүрэн итгэлтэй байсангүй цаг_тогтоосон цаг и өдрийн цаг, тиймээс эхний туршилтын хувьд би бүх "тохиромжтой" дуудлагуудыг сонгосон:
# 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, stime, timerfd_create, аль auditctl үүнийг таньсангүй, эхлээд дараах хэлбэрээр аудит эхлүүлсэн.
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 нь хоёртын хувилбараас хөрвүүлэхдээ гаралтыг огноогоор нь эрэмбэлсэн бөгөөд үйл явдал бидний тогтоосон цагт болсон тул дээрх тайланд энэ нь дууссан. огноо -s "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 - Манай шимэгч олдсон. Хэдийгээр "хорлонтой" зан авиртай ч нөхцөлт хандалтын системээс татгалзах боломжгүй ч би мэдэхийг хүсч байна. Оскам, WTF?
Хариулт нь хурдан олддог :
#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");
}
Энд ямар хөөрхөн харагдаж байна тайлбар хийлээ шугам анхааруулга...
Эх сурвалж: www.habr.com