რაც უფრო მარტივია დავალება, მით უფრო ხშირად ვუშვებ შეცდომებს

ეს ტრივიალური ამოცანა გაჩნდა ერთ პარასკევს შუადღისას და 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 ნაკადის ამოღების უზრუნველსაყოფად არის "ფირფიტებიდან" მომავალი კაბელების გათიშვა. საბედნიეროდ, სერვერი კედლის მიღმაა, ასეც იყოს.

რა თქმა უნდა, ჟურნალები რომ შეიცავდეს იმას, რაც იქ უნდა ყოფილიყო, ეს არ მოხდებოდა, მაგრამ უფრო ამის შესახებ, კიდევ ერთხელ, სტატიის ბოლოს.

ისე, რადგან ჩვენ უკვე წავშალეთ ყველა სატელიტური სიგნალი, ჩვენ ასევე მოვხსნით ხმელეთის სიგნალებს - ამავდროულად ვიღებთ ქსელის ყველა კაბელს. სერვერი მოწყვეტილია გარე სამყაროსგან და მუშაობს სრულიად ავტონომიურად, მაგრამ სისტემის საათი მაინც ჩქარობს.

სამუშაო კვირა დასრულდა და თარიღის/დროის საკითხი თავისთავად არ არის კრიტიკული, ასე რომ თქვენ შეგიძლიათ სახლში წასვლა, მაგრამ აქ მე ვუშვებ ახალ შეცდომას.

შეცდომა სამი. მრჩევლები

არასოდეს! არასოდეს დაუსვათ შეკითხვები ფორუმებზე და ზოგად სპეციალიზებულ (a la stackoverflow) საიტებზე, თუ მასზე პასუხი მოითხოვს უფრო მეტს, ვიდრე Google-ის პირველი გვერდის შესწავლა და ერთი კაცის გვერდის კითხვა.

დაგიბრუნებენ გუგლში, წაიკითხავენ იგივე კაცს და პოპულარულად აგიხსნიან ფორუმის/საიტის წესებს, მაგრამ პასუხს არ გაგცემენ.

აქ არის რამდენიმე ობიექტური ფაქტორი:

• თქვენ გარდა ვერავინ შეძლებს პრობლემის ცოდნას;
• ვერავინ შეძლებს ტესტების ჩატარებას თქვენს პირობებში

და სუბიექტური:

• შესაძლოა, პრობლემის გადასაჭრელად მთელი წვლილის შეტანა არ მოგცეთ, რადგან უკვე მოიფიქრეთ „სწორი“ მიმართულება და მასზე ფოკუსირებული წარმოადგენთ საკითხის არსს;
• ოსტატი (მოდერატორი, ძველი ტაიმერი, ადმინი) ყოველთვის მართალია, თუ ოსტატი ცდება... აბა, თქვენ იცით...

თუ კომენტარებზე პასუხის გაცემისას ცენზურირებული ლექსიკის ფარგლებში დარჩით, მაშინ ძლიერი ნერვები გაქვთ.

გადაწყვეტილება

არ არის საჭირო დავალებების დაყოფა მარტივ და რთულად.

ჩვენ ვწყვეტთ ჩვენს გამოცდილებას, სტატისტიკას, მრჩეველს და ვიწყებთ არა საბოლოო შედეგის „ახსნას“, არამედ მიზეზის თანმიმდევრულად ძიებას.

ვინაიდან ვინმე ადგენს დროს, შესაბამისი სისტემური ზარი უნდა მოხდეს.

როგორც პროგრამულ დოკუმენტაციაში საუკეთესო დოკუმენტებია წყაროები, ასევე სისტემის ადმინისტრირებაში საუკეთესო ასისტენტი არის აუდიტი, ჩვენს შემთხვევაში. აუდიტი.

ეჭვის მომენტიმე გავიარე მანა, მაგრამ ბოლომდე დარწმუნებული არ ვიყავი, რომ Linux-ში დროის დაყენება მხოლოდ შესაძლებელია საათის_დაყენების დრო и დღის დანიშვნაასე რომ, პირველი ტესტისთვის მე ავირჩიე ყველა "შესაფერისი" ზარი:

# 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-მა დაალაგა გამომავალი თარიღის მიხედვით, როდესაც კონვერტაცია ორობითი იყო, და მოვლენა მოხდა იმ დროს, როდესაც ჩვენ ვაყენებდით თარიღი -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