این کار بی اهمیت یک بعد از ظهر جمعه به وجود آمد و باید 2-3 دقیقه زمان می برد. در کل مثل همیشه.
یکی از همکاران از من خواست که اسکریپت را روی سرورش تعمیر کنم. من این کار را انجام دادم، آن را به او دادم و ناخواسته زمین خوردم: "زمان 5 دقیقه سریع است." اجازه دهید سرور خودش همگام سازی را انجام دهد. نیم ساعت، یک ساعت گذشت و او همچنان پف می کرد و آرام فحش می داد.
"احمق! - فکر کردم، با رفتن به کنسول سرور - بسیار خوب، چند دقیقه دیگر استراحت خواهم کرد.
ما نگاه می کنیم ntp، rdate، sdwdate نصب نشده timesyncd غیر فعال است و اجرا نمی شود.
# 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، جدا کردن کابل‌هایی است که از "صفحات" می‌آیند. خوشبختانه سرور پشت دیوار است، پس همینطور باشد.
البته، اگر لاگ ها حاوی مواردی بودند که باید وجود داشته باشند، این اتفاق نمی افتاد، اما بیشتر در مورد آن، دوباره در پایان مقاله.
خوب، از آنجایی که ما قبلاً همه سیگنال های ماهواره را حذف کرده ایم، سیگنال های زمینی را نیز حذف می کنیم - در همان زمان همه کابل های شبکه را بیرون می آوریم. سرور از دنیای خارج قطع می شود و کاملاً مستقل کار می کند، اما ساعت سیستم هنوز هم عجله دارد.
هفته کاری تمام شده است و موضوع تاریخ/زمان به خودی خود مهم نیست، بنابراین شما می توانید به خانه بروید، اما در اینجا من یک اشتباه جدید مرتکب می شوم.
خطای سه. مشاوران
هرگز! هرگز در انجمن ها و سایت های تخصصی عمومی (a la stackoverflow) سوال نپرسید، اگر پاسخ به آن چیزی بیش از مطالعه صفحه اول گوگل و خواندن یک صفحه مرد نیاز دارد.
آنها شما را دوباره به گوگل می فرستند، همان مرد را می خوانند و قوانین انجمن/سایت را به طور عمومی توضیح می دهند، اما پاسخی به شما نمی دهند.
در اینجا برخی از عوامل عینی وجود دارد:
- هیچ کس به جز شما نمی تواند مشکل را نیز بداند.
- هیچ کس نمی تواند تحت شرایط مشابه شما تست انجام دهد
و ذهنی:
- ممکن است تمام ورودی ها را برای حل مشکل ارائه ندهید، زیرا قبلاً جهت "درست" را پیدا کرده اید و ماهیت موضوع را با تمرکز بر آن ارائه می دهید.
- سرکارگر (مدیریت، قدیمی، ادمین) همیشه درست می گوید، اگر سرکارگر اشتباه می کند... خوب، می دانید...
اگر هنگام پاسخ دادن به نظرات، در محدوده واژگان سانسور شده باقی ماندید، پس اعصابتان قوی است.
تصمیم
نیازی به تقسیم وظایف به ساده و پیچیده نیست.
ما به تجربه، آمار، مشاوران خود تکیه نمی کنیم و شروع به "توضیح" نتیجه نهایی نمی کنیم، بلکه به طور مداوم به دنبال دلیل می گردیم.
از آنجایی که شخصی زمان را تعیین می کند، تماس سیستم مربوطه باید رخ دهد.
همانطور که در اسناد نرم افزاری بهترین اسناد منبع هستند، در مدیریت سیستم نیز بهترین دستیار حسابرسی است، در مورد ما حسابرسی شده است.
یک لحظه شکمن از طریق مانا رفتم، اما کاملاً مطمئن نبودم که زمان در لینوکس فقط قابل تنظیم است ساعت_تنظیم и ساعت روز، بنابراین برای اولین آزمایش همه فراخوانی های "مناسب" را انتخاب کردم:
# 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 -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پس از اطمینان از اینکه هیچ گزارش دیگری در مکان های گزارش مورد علاقه من وجود ندارد syscals علاوه بر این دو، من فقط از آنها استفاده کردم.
اجرای ممیزی تماس سیستمی ساعت_تنظیم и ساعت روز و سعی کنید تاریخ را تغییر دهید:
# 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 هنگام تبدیل از باینری خروجی را بر اساس تاریخ مرتب کرد و رویداد در زمانی رخ داد که ما تنظیم کردیم. date -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