🍏 🔒 🐈 कार्य जितना सरल है, उतनी ही बार मुझसे गलती होती है 🐫 🏴󠁧󠁢󠁥󠁮󠁧󠁿 ⏲️

यह तुच्छ कार्य शुक्रवार के दिनों में से एक पर उठता है और इसमें 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

समय एक दूसरे विभाजन के लिए निर्धारित किया जाता है, और फिर "जल्दी" शुरू होता है।

उसी समय, लॉग में, इस तरह के एक मैनुअल परिवर्तन के समय, हम केवल सिस्टम रिपोर्ट देखते हैं कि समय बदल गया है, क्रमशः सही / गलत दिशा में और कभी-कभी सिस्टमड -टाइमसेंडीक्स से रिसाइनिंग।

 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

पुनरुत्थान चला गया है और बाकी लॉग प्राचीन हैं।

हम सभी इंटरफेस पर 123 वें पोर्ट पर tcpdump आउटपुट की जांच करते हैं। कोई अनुरोध नहीं है, लेकिन समय भी दूर चल रहा है।

दूसरी गलती। जल्दी

काम के सप्ताह के अंत तक एक घंटे बाकी है, लेकिन आप बुरे काम के साथ सप्ताहांत के लिए नहीं छोड़ना चाहते हैं (कोड में समय पर ध्यान न दें, यह लेख निम्नलिखित दिनों में लिखा गया था)।
और यहाँ फिर से, एक कारण की तलाश के बजाय, मैं परिणाम के लिए स्पष्टीकरण के साथ आने की कोशिश करने लगा। मैं कहता हूं "आविष्कार", क्योंकि परिणाम के लिए स्पष्टीकरण कितना भी तार्किक क्यों न हो, यह समस्या को हल करने का एक गलत तरीका है।

यह सर्वर स्ट्रीमिंग है और DVB-S2 स्ट्रीम को IP में कनवर्ट करता है। डीवीबी-एस स्ट्रीम में टाइमस्टैम्प हैं, इसलिए रिसीवर, मल्टीप्लेक्सर्स, स्क्रैम्बलर और टीवी अक्सर सिस्टम घड़ी को सिंक्रनाइज़ करने के लिए उनका उपयोग करते हैं। DVB-S बोर्डों के लिए ड्राइवर कर्नेल में संकलित किए जाते हैं, इसलिए एक साफ DVB-S2 स्ट्रीम की गारंटी देने का सबसे तेज़ तरीका "प्लेट" से आने वाले केबल को डिस्कनेक्ट करना है। सौभाग्य से, सर्वर दीवार के पीछे है, इसलिए, ऐसा हो।

बेशक, अगर लॉग में क्या होना चाहिए था, यह नहीं हुआ होगा, लेकिन उस पर और अधिक, फिर से, लेख के अंत में।

खैर, चूंकि हमने पहले ही सभी उपग्रह संकेतों को हटा दिया है, इसलिए हम स्थलीय को भी हटा देंगे - जिस तरह से हम सभी नेटवर्क केबलों को बाहर निकालते हैं। सर्वर बाहरी दुनिया से कट जाता है और पूरी तरह से स्वायत्तता से काम करता है, लेकिन सिस्टम क्लॉक अभी भी जल्दी में है।

कार्य सप्ताह समाप्त हो गया है, और इस पर तारीख / समय का प्रश्न महत्वपूर्ण नहीं है, इसलिए आप बस घर जा सकते हैं, लेकिन यहां मैं एक नई गलती करता हूं।

तीसरी गलती। सलाहकारों

कभी नहीं! कभी भी फ़ोरम पर सवाल न पूछें और आम तौर पर विशिष्ट (एक ला स्टैवेरोफ़्लो) साइटें अगर इसका उत्तर Google के पहले पृष्ठ के जारी होने और मानव के एक पृष्ठ को पढ़ने से अधिक आवश्यक है।

आपको 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, टाइमरfd_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

यह सुनिश्चित करने के बाद कि लॉग्स के स्थानों में जो मुझे रुचि रखते हैं, इन दोनों के अलावा कोई अन्य सिसकल्स नहीं हैं, मैंने केवल उनका उपयोग किया।

हम सिस्टम कॉल क्लॉक_सेटटाइम और सेटाइमटाइम का ऑडिट शुरू करते हैं और तारीख बदलने की कोशिश करते हैं:

 # 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_proces देखते हैं । यह उपरोक्त रिपोर्ट में निकला, क्योंकि बाइनरी दृश्य से परिवर्तित होने के बाद 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 / स्थानीय / बिन / ऑसम - हमारा परजीवी पाया गया। अपने "दुर्भावनापूर्ण" व्यवहार के बावजूद, सशर्त पहुंच प्रणाली को छोड़ना असंभव है, लेकिन फिर भी मैं जानना चाहूंगा, ऑसम , डब्ल्यूटीएफ?

उत्तर जल्दी से स्रोत में पाया जाता है:

 #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"); }

कमेंट-आउट चेतावनी लाइन कितनी अच्छी लगती है यहां ...

कार्य जितना सरल है, उतनी ही बार मुझसे गलती होती है

पहली गलती। आत्म विश्वास

दूसरी गलती। जल्दी

तीसरी गलती। सलाहकारों

निर्णय

More articles: