जो जाँचें कभी फ़ेल नहीं हो सकतीं: Mac ऑटोमेशन के एक हफ़्ते से पाँच false positive
एक नियम हमारा लगभग पूरा हफ़्ता बचा लेता। किसी जाँच पर भरोसा करने से पहले पूछें कि चीज़ ख़राब होने पर वह क्या प्रिंट करती है। अगर जवाब है "वही चीज़", तो आपके पास जाँच नहीं है। आपके पास बस एक सजावट है, जो OK कहती है।
यहाँ ऐसी पाँच जाँचें हैं, जो हमें एक हफ़्ते में मिलीं। सब macOS पर थीं, और सब ऐसे ऑटोमेशन में थीं जो महीनों से बिना शिकायत चल रहा था। हर एक ने पूरे भरोसे से गलत जवाब दिया। और हर एक ने किसी इंसान को ऐसी चीज़ ठीक करने भेजा जो ख़राब ही नहीं थी।
| जाँच | ठीक होने पर क्या दिखता है | खराब होने पर क्या दिखता है | नतीजा |
|---|---|---|---|
| pgrep -f softwareupdate | idle डेमन से मैच | idle डेमन से मैच | बेकार |
| tar -xf - ; echo COPIED | COPIED | COPIED (0 bytes) | बेकार |
| kickstart privilege probe | कोई चेतावनी प्रिंट नहीं | कुछ भी प्रिंट नहीं | बेकार |
| stat -f %Su /dev/console | root | root | बेकार |
| sysadminctl -autologin set | error:22 | error:22 | बेकार |
1. वह अपडेट जो चल ही नहीं रहा था
एक मशीन रीबूट के बाद धीरे वापस आती लगी। एक छोटे से pgrep -f softwareupdate को मैच मिल गया। इसलिए स्क्रिप्ट ने बताया कि सॉफ़्टवेयर अपडेट चल रहा है, और हम इंतज़ार करते रहे।
कोई अपडेट नहीं था। softwareupdated हर Mac पर हमेशा चलने वाला डेमन है। सबस्ट्रिंग मैच उसे ढूँढ ही लेता है, चाहे कुछ हो रहा हो या नहीं। मशीन के मालिक ने एक सीधे सवाल से इसे पकड़ा: कोई अपडेट होना ही नहीं चाहिए, तो समस्या क्या है? जाँच के पास कोई जवाब नहीं था, क्योंकि उसके पास कभी जवाब था ही नहीं।
फ़िक्स यह है कि चलता अपडेट जो निशान छोड़ता है, उसे देखें। चलता हुआ डाउनलोड या लगातार डिस्क गतिविधि सबूत है। हमेशा मौजूद रहने वाला प्रोसेस का नाम सबूत नहीं है।
2. वह Xcode जो शून्य सेकंड में कॉपी हो गया
हम मशीनों के बीच Xcode को SSH पर tar आर्काइव स्ट्रीम करके क्लोन करते हैं। एक बार यह एक लैपटॉप से होकर गया, जिसकी मेमोरी ख़त्म हो गई। भेजने वाली तरफ़ बंद हो गई। पाने वाले tar -xf - ने ख़ाली स्ट्रीम पढ़ी, कुछ नहीं निकाला, और शून्य के साथ बाहर निकला। स्क्रिप्ट ने XCODE_COPIED प्रिंट किया।
शून्य बाइट गए थे। एग्ज़िट कोड उस काम के बारे में सच था जो tar को दिया गया था, यानी जो भी आए उसे निकालना। कुछ आया ही नहीं।
# what we checked tar -xf - -C /Applications && echo XCODE_COPIED # what we should have checked du -sh /Applications/Xcode.app # 3.8G, or it did not happen /Applications/Xcode.app/Contents/Developer/usr/bin/xcodebuild -version
3. वह परमिशन जिसे मिला हुआ बताया गया
macOS स्क्रीन रिकॉर्डिंग को एक प्रिविलेज के पीछे रखता है, जिसे सिर्फ़ कोई इंसान या MDM प्रोफ़ाइल दे सकती है। प्रिविलेज न होने पर Apple का kickstart टूल साफ़ चेतावनी प्रिंट करता है। हमारी जाँच वही चेतावनी ढूँढती थी। चेतावनी न मिलने पर वह प्रिविलेज को मिला हुआ बताती थी।
जब टूल के पास कोई प्रिविलेज ही न हो, तो वह कुछ प्रिंट नहीं करता। न चेतावनी, न कुछ और। चेतावनी का न होना बिल्कुल सफलता जैसा दिखा। पूरी कहानी वह Mac जो लॉग इन तो करता है, पर कुछ नहीं दिखाता में है। फ़िक्स यह था कि टूल की राय पूछना बंद करें और फ़्रेमबफ़र से असली पिक्सेल का सैंपल लें।
4. वह डेस्कटॉप जिसे बंद बताया गया
यह पक्का करने के लिए कि यूज़र GUI में लॉग इन है, हमने देखा कि /dev/console का मालिक कौन है। नई मशीन पर इसने root बताया, तो हमने मान लिया कि कोई लॉग इन नहीं है। फिर हमने एक ग्राहक की मशीन देखी, जिस पर दो दिन से एक यूज़र लॉग इन था। उसने भी root बताया।
लगभग दस मिनट तक एक पैसे देने वाले ग्राहक का डेस्कटॉप बंद बताया गया। वह ठीक था। डिवाइस नोड का मालिक होना वह मतलब रखता ही नहीं जो हमने माना था। who सिर्फ़ तभी console लाइन दिखाता है जब सेशन मौजूद हो। अब हमारी टेलीमेट्री यही बताती है।
5. वह एरर जो हमेशा एक जैसा था
बिल्कुल नए macOS मेजर वर्ज़न वाली एक मशीन ऑटो-लॉगिन नहीं कर रही थी। Apple के sysadminctl -autologin set ने SACSetAutoLoginPassword error:22 लौटाया। नया OS, नया एरर, साफ़ नतीजा: नई रिलीज़ ने स्क्रिप्ट वाला ऑटो-लॉगिन तोड़ दिया।
फिर हमने वही कमांड एक मेजर वर्ज़न पीछे वाली ठीक मशीन पर चलाई, जहाँ ऑटो-लॉगिन हफ़्तों से चल रहा था। वही एरर। यह कमांड ठीक और ख़राब, दोनों सिस्टम पर एक जैसे फ़ेल होती है। इसलिए इससे किसी के बारे में कोई जानकारी नहीं मिली। असली वजह पहले बूट की एक अस्थायी स्थिति निकली। पूरे भरोसे वाला निदान गलत था। कंट्रोल ने उसे एक मिनट से कम में गलत साबित कर दिया।
नियम, और उससे निकलने वाली दो बातें
पाँचों जाँचें पहले सवाल पर फ़ेल होती हैं। इनके पीछे भागने में चार दिन गए। असली सिस्टम में से कोई भी उस तरह ख़राब नहीं था जैसा जाँचें दावा कर रही थीं।
क्या बदला
स्क्रीन की जाँच फ़्रेमबफ़र का सैंपल लेकर रंग गिनती है। सेशन की जाँच who इस्तेमाल करती है और टेलीमेट्री में जाती है। इसलिए लॉगिन विंडो पर अटकी मशीन ठीक दिखने की जगह अलर्ट देती है। कॉपी की पुष्टि साइज़ से और कॉपी हुई बाइनरी चलाकर होती है। और किसी फ़ेलियर की मूल वजह तब तक तय नहीं होती, जब तक वही जाँच किसी ठीक चलती चीज़ पर न चलाई जाए। इसमें कोई चालाकी नहीं है। सब वही एक सवाल है, जो जाँच लिखने से पहले पूछा जाता है, उसके झूठ बोलने के बाद नहीं।
अपना हिसाब खुद लगाएँ: कैलकुलेटर देखें, या एक runner लीज़ करें।