समस्या-निवारण

Signal Lab जो भी विफलता बताता है उसका एक कोड होता है; हर एक का संदेश त्रुटि संदेश में है। नेटवर्क विफलताएँ transport कोड हैं: refused, timeout, dns, unreachable, reset, address_in_use, address_unavailable, denied, tls, target_invalid, failed. नीचे दी गई समस्याएँ आम हैं।

कुछ नहीं पहुँचता

पहले पता करें कि Signal Lab तक कुछ पहुँचता भी है या नहीं: निचले पैनल में इंस्पेक्टर टैब खोलें और कैप्चर चालू करें दबाएँ। कोई टूल जो भी डेटाग्राम, रिक्वेस्ट और संदेश भेजता या प्राप्त करता है, वह सब वहाँ उसके स्रोत के साथ सूचीबद्ध होता है।

सुनने का पता

• 0.0.0.0:<port> का बाइंड पता हर नेटवर्क कार्ड पर सुनता है; 127.0.0.1:<port> केवल इसी मशीन को सुनता है। नेटवर्क पर मौजूद उपकरण को पहला चाहिए।
• उपकरण को इस मशीन के पते और उस पोर्ट पर भेजना चाहिए जिस पर आप सुनते हैं। हेडर इस मशीन का नाम और पता दिखाता है।
• जो पता इस मशीन का नहीं है, वह address_unavailable के साथ विफल होता है।

फ़ायरवॉल

127.0.0.1 पर ट्रैफ़िक कभी फ़िल्टर नहीं होता, इसीलिए एक मशीन पर परीक्षण चल जाता है जबकि किसी दूसरी मशीन से वही परीक्षण कुछ नहीं पाता।

Windows. Windows फ़ायरवॉल प्रति प्रोग्राम तय करता है। Windows आम तौर पर एक बार पूछता है, जब कोई प्रोग्राम पहली बार सुनता है — और वहाँ Cancel करने से एक नियम रह जाता है जो उसे ब्लॉक करता है, और वह किसी भी allow नियम पर भारी पड़ता है। ऐसे नेटवर्क पर जिसे Windows public कहता है (अक्सर किसी स्थल का Wi-Fi), वह शायद पूछे ही नहीं।

• डेस्कटॉप ऐप फ़ायरवॉल को एक बार देखता है, जब कोई मॉनिटर, डिस्कवरी लिसनर, रिले, रन या एमुलेटर सुनना शुरू करता है। जब फ़ायरवॉल आड़े आता है तो वह अनुमति दें वाली सूचना में बताता है — या public नेटवर्क पर अनुमति दें, सार्वजनिक नेटवर्क पर भी। Windows एडमिनिस्ट्रेटर अधिकार माँगता है, फिर प्रोग्राम के inbound नियम, ब्लॉक नियम सहित, एक allow नियम से बदल दिए जाते हैं। अभी नहीं सूचना छिपा देता है।
• टर्मिनल से: signallab doctor दिखाता है कि क्या आड़े आ रहा है, और signallab firewall allow उसे ठीक करता है (public नेटवर्क के लिए भी --public), उसी एडमिनिस्ट्रेटर प्रॉम्प्ट के साथ।
• सबके लिए इंस्टॉल किया गया सेटअप (.exe) allow नियम ख़ुद जोड़ देता है (private और domain नेटवर्क), जब तक वह /NOFIREWALL के साथ न चलाया गया हो। मेरे लिए वाला सेटअप ऐसा नहीं कर सकता, और .msi फ़ायरवॉल उसी पर छोड़ देता है जो उसे तैनात करता है।
• सर्वर अपने होस्ट का फ़ायरवॉल कभी नहीं बदलता: उसका एडमिनिस्ट्रेटर पोर्ट खोलता है (इंस्टॉल स्क्रिप्ट ufw या firewalld के साथ ऐसा करने का प्रस्ताव देती है)।

Linux. ufw या firewalld जैसा फ़ायरवॉल पोर्ट से काम करता है, प्रोग्राम से नहीं। signallab doctor बताता है कि कौन चालू है और कोई पोर्ट कैसे खोलें, जैसे sudo ufw allow 9000/udp.

ब्रॉडकास्ट और मल्टीकास्ट

• राउटर ब्रॉडकास्ट आगे नहीं भेजते: 255.255.255.255 और x.x.x.255 केवल उसी नेटवर्क खंड तक पहुँचते हैं जिस पर भेजने वाला कार्ड है। कई कार्ड होने पर, कार्ड का पता बाइंड (स्रोत) में डालें (सॉकेट विकल्प के नीचे), जैसे 10.0.0.5:0.
• मल्टीकास्ट डेटाग्राम केवल उन लिसनर तक पहुँचता है जो उसके समूह से जुड़े हैं — डिस्कवरी लिसनर पर, मल्टीकास्ट ग्रुप जॉइन करें। TTL / हॉप के 1 (डिफ़ॉल्ट) पर वह इसी नेटवर्क पर रहता है।
• एक ही मशीन पर अपना मल्टीकास्ट सुनने के लिए, इसी होस्ट पर वापस लूप करें चालू रहने दें।

वह उपकरण जो जवाब नहीं देता

UDP में डिलीवरी रसीद नहीं होती: ऐसे पोर्ट पर भेजा डेटाग्राम जिस पर कोई नहीं सुनता, फिर भी भेजा हुआ गिना जाता है। Windows फिर उसे मिले ICMP port unreachable को उस सॉकेट की अगली प्राप्ति पर कनेक्शन रीसेट के रूप में बताता है; Signal Lab के मॉनिटर, लिसनर, रिले और waits उसे अनदेखा कर सुनते रहते हैं। इसलिए जब जवाब न आए, तो एक wait अपने समय के बाद wait.timeout के साथ विफल होता है, भेजने के बारे में किसी त्रुटि के साथ नहीं। इंस्पेक्टर में जाँचें कि संदेश सही पते पर गया, फिर उपकरण जाँचें।

भेजा जाना निकलने से पहले अस्वीकार हो जाता है

ये पहले जाँचे जाते हैं, और कोई एक विफल हो तो कुछ नहीं भेजा जाता:

कोड	क्यों	ठीक करें
transport.target_invalid	गंतव्य में पोर्ट नहीं, या वह न IP:port है न host:port	दोनों लिखें, जैसे 192.0.2.20:9000
transport.dns	होस्ट नाम इस मशीन पर रिज़ॉल्व नहीं होता	नाम जाँचें, या पता उपयोग करें। IPv4 पते वाला नाम IPv4 पर पहुँचता है, इसलिए localhost:9000 127.0.0.1 पर कोई रिसीवर पा लेता है
node.osc_address	कोई OSC पता / से शुरू नहीं होता — प्रेषक में, जनरेटर में, किसी सिग्नल या चरण में	उसे / से शुरू करें, जैसे /cue/go
node.topic_wildcard	MQTT publish के topic में + या # है, स्क्रीन के कनेक्शन पर जैसे हर जगह	एक ही topic पर publish करें; वाइल्डकार्ड सब्सक्राइब के लिए हैं
WebSocket संदेश पर node.too_long	संदेश 16 MiB से अधिक है	कम भेजें; कनेक्शन खुला रहता है

कोई पोर्ट पहले से व्यस्त है

transport.address_in_use: कोई दूसरा प्रोग्राम — या Signal Lab का कोई दूसरा जॉब — उस पोर्ट पर पहले से सुन रहा है।

• एक मॉनिटर और एक रन। रन अपने पहले चरण से पहले अपने waits, emulators और relays के पोर्ट खोल देता है, इसलिए मॉनिटर, किसी डिस्कवरी लिसनर या किसी एमुलेटर जॉब के अधिकार में रहा पोर्ट रन को शुरू होने से पहले विफल कर देता है। पहले वह जॉब रोकें; सभी रोकें हर एक को रोक देता है।
• एक रन में दो एमुलेटर एक ही ट्रांसपोर्ट का पोर्ट साझा नहीं कर सकते: HTTP, MQTT और TCP एमुलेटर सब TCP पर सुनते हैं, OSC और UDP वाले UDP पर (emulator.bind_taken)।
• असली सेवा के बगल में सुनना। डिस्कवरी लिसनर ऐसे प्रोग्राम के साथ पोर्ट साझा कर सकता है जिसके पास वह पहले से है: पोर्ट साझा करें चालू रहने दें। Linux पर, उस प्रोग्राम को भी अपना पोर्ट साझा करना चाहिए। इसके बिना, लिया हुआ पोर्ट broadcast.port_shared है।
• अभी-अभी रोका। रुके हुए एमुलेटर या रन का पकड़ा पोर्ट एक पल बाद छूट जाता है; तुरंत फिर शुरू किया एमुलेटर उसके लिए थोड़ी देर प्रतीक्षा करता है।
• Linux पर 1024 से नीचे के पोर्ट के लिए एडमिनिस्ट्रेटर अधिकार चाहिए (denied)। सर्वर इमेज बिना किसी के चलती है, इसलिए 1024 या उससे ऊपर का पोर्ट उपयोग करें।

Docker में सर्वर नेटवर्क तक नहीं पहुँचता

ब्रॉडकास्ट, मल्टीकास्ट और डिस्कवरी भौतिक नेटवर्क तक केवल होस्ट नेटवर्किंग के साथ पहुँचते हैं — compose फ़ाइल में network_mode: host, या docker run --network host — और केवल Linux होस्ट पर। यह मॉनिटर, waits और emulators को होस्ट के ही पोर्ट पर सुनने भी देता है। Docker के डिफ़ॉल्ट ब्रिज नेटवर्क के साथ, कंटेनर अपने नेटवर्क पर होता है: ब्रॉडकास्ट और मल्टीकास्ट उससे कभी बाहर नहीं जाते, और केवल वही पोर्ट उस तक पहुँचते हैं जो आप प्रकाशित करते हैं।

Windows और macOS पर, Docker की होस्ट नेटवर्किंग भौतिक नेटवर्क तक नहीं पहुँचती: Windows पर डेस्कटॉप ऐप उपयोग करें, या सर्वर किसी Linux होस्ट पर चलाएँ।

SmartScreen इंस्टॉलर के बारे में चेतावनी देता है

इंस्टॉलर अभी हस्ताक्षरित नहीं हैं, इसलिए Windows SmartScreen कहता है कि वह प्रकाशक को नहीं जानता। More info, फिर Run anyway चुनें। इंस्टॉलर केवल GitHub पर प्रोजेक्ट की रिलीज़ से डाउनलोड करें।

सर्वर शुरू नहीं होता

signal-lab-server सुनने से पहले अपनी सेटिंग्स जाँचता है और अपने error output पर संदेश के साथ बाहर निकलता है:

एग्ज़िट कोड	संदेश	ठीक करें
2	refusing to listen on … without a token	दूसरों की पहुँच वाले सर्वर को टोकन चाहिए: --token-file या SIGNALLAB_TOKEN (signal-lab-server token से एक बनाएँ), या --generate-token। या 127.0.0.1 पर सुनें
2	the token has N characters; it needs at least 24	लंबा टोकन उपयोग करें
2	the token must not contain spaces or line breaks	टोकन फ़ाइल लाइन ब्रेक पर समाप्त हो सकती है; और कुछ नहीं
2	give the token once	--token/SIGNALLAB_TOKEN या --token-file/SIGNALLAB_TOKEN_FILE में से एक उपयोग करें, दोनों नहीं
2	--generate-token keeps the token in the data folder	--data-dir या SIGNALLAB_DATA_DIR सेट करें
2	… it does not hold a valid token; remove it to have a new one made	डेटा फ़ोल्डर की token फ़ाइल ख़राब है
2	cannot read the token file …	--token-file द्वारा बताई फ़ाइल नहीं है या इस उपयोगकर्ता से पढ़ने योग्य नहीं
2	cannot save the new token in …	--generate-token डेटा फ़ोल्डर में token नहीं लिख सका: फ़ोल्डर को इस उपयोगकर्ता से लिखने योग्य बनाएँ
1	cannot listen on …	पता इस मशीन का नहीं, या पोर्ट लिया हुआ है
1	the data folder … must be writable by this user	Docker में, bind-mount किया फ़ोल्डर uid 10001 से लिखने योग्य होना चाहिए

--generate-token की बनाई टोकन एक बार छपती है, पहली बार शुरू होने पर (docker logs signallab उसे दिखाता है), और डेटा फ़ोल्डर में token में रखी जाती है: docker exec signallab cat /data/token. देखें सर्वर।

सर्वर में साइन इन नहीं कर पा रहे

आपको क्या दिखता है	क्यों	ठीक करें
That token is not right.	ग़लत टोकन	इसे वहाँ से फिर कॉपी करें जहाँ सर्वर रखता है; जवाब जान-बूझकर एक सेकंड लेता है
auth.host	सर्वर ऐड्रेस बार में लिखे नाम को जवाब नहीं देता	इसे किसी स्वीकार्य नाम से खोलें। लूपबैक नाम (localhost, 127.x.x.x, [::1]) हमेशा पास होते हैं। टोकन के बिना सर्वर केवल उन्हीं और --allowed-host के नामों को जवाब देता है; टोकन के साथ, किसी भी नाम को जब तक --allowed-host उसे सीमित न कर दे
auth.origin	किसी दूसरे ओरिजिन के पेज से रिक्वेस्ट आई	रिवर्स प्रॉक्सी के पीछे, ब्राउज़र का Host सर्वर तक भेजें (nginx: proxy_set_header Host $host;), ताकि Origin और Host मेल खाएँ
साइन इन करने के बाद फिर साइन-इन पेज पर	ब्राउज़र ने सेशन कुकी नहीं रखी	--secure-cookie के साथ, सर्वर तक HTTPS से पहुँचना चाहिए
थोड़ी देर बाद साइन आउट	सेशन 7 दिन चलते हैं और सर्वर के रीस्टार्ट पर समाप्त हो जाते हैं; 1024 सेशन से आगे सबसे पुराना चला जाता है	फिर साइन इन करें

सर्वर से कनेक्शन बार-बार टूटता है

सर्वर से कनेक्शन टूट गया — फिर से कनेक्ट हो रहा है… का अर्थ है कि पेज का इवेंट सॉकेट, /api/events, बंद हो गया। पेज अपने आप फिर जुड़ जाता है, आधे सेकंड बाद और फिर कम बार, अधिकतम हर 15 सेकंड में। बीच में जो हुआ वह दोबारा नहीं चलाया जाता: चल रहे जॉब आगे बढ़ते हुए फिर बताते रहते हैं। रिवर्स प्रॉक्सी के पीछे, सुनिश्चित करें कि वह /api/events के लिए WebSocket अपग्रेड आगे भेजता है और शांत कनेक्शन 20 सेकंड से कम में बंद नहीं करता (सर्वर हर 20 सेकंड में ping करता है)। जो पेज कहता है कि सर्वर का ऐसा कोई पता नहीं (api.not_found) वह सर्वर से पुराना है: उसे फिर लोड करें।

MQTT कनेक्ट नहीं होता

Signal Lab सादे TCP पर MQTT 3.1.1 बोलता है। यह सफलता बताने से पहले ब्रोकर के जवाब (CONNACK) की प्रतीक्षा करता है, इसलिए कारण कनेक्ट करने वाले बटन पर होता है:

कोड	क्यों	ठीक करें
transport.refused	उस पोर्ट पर कोई नहीं सुनता	पोर्ट जाँचें: 1883 आम है
transport.timeout	6 सेकंड में कोई TCP कनेक्शन नहीं	पता, नेटवर्क, ब्रोकर का फ़ायरवॉल जाँचें
transport.dns	होस्ट नाम रिज़ॉल्व नहीं होता	नाम जाँचें, या पता उपयोग करें
transport.unreachable	ब्रोकर तक कोई रूट नहीं	नेटवर्क और पता जाँचें
transport.reset	ब्रोकर ने तुरंत कनेक्शन बंद कर दिया	अक्सर यह TLS पोर्ट (8883) होता है — Signal Lab TLS पर MQTT नहीं बोलता
mqtt.no_answer	पोर्ट खुला है, पर 6 सेकंड में कोई CONNACK नहीं आया	अक्सर यह WebSocket पोर्ट होता है — Signal Lab WebSocket पर MQTT नहीं बोलता
mqtt.protocol	जिसने जवाब दिया वह MQTT ब्रोकर नहीं है	पोर्ट जाँचें
mqtt.refused_protocol	ब्रोकर MQTT 3.1.1 स्वीकार नहीं करता	ब्रोकर पर 3.1.1 चालू करें
mqtt.refused_client_id	ब्रोकर client id अस्वीकार करता है	दूसरी client id उपयोग करें
mqtt.refused_unavailable	ब्रोकर अनुपलब्ध है	बाद में फिर प्रयास करें
mqtt.refused_credentials	उपयोगकर्ता नाम या पासवर्ड ग़लत है	उन्हें जाँचें
mqtt.refused_not_authorized	उपयोगकर्ता कनेक्ट नहीं कर सकता	ब्रोकर के एक्सेस नियम जाँचें
mqtt.client_id_required	client id खाली है	उसे भरें

एक ही client id वाले दो कनेक्शन में से ब्रोकर पुराने को गिरा देता है: जब कोई कनेक्शन बार-बार बंद हो, तो उसी id का कोई दूसरा क्लाइंट खोजें।

कोई प्रमाणपत्र भरोसेमंद नहीं है

https:// या wss:// पर transport.tls: सर्वर का प्रमाणपत्र भरोसेमंद नहीं है, उस होस्ट का नाम नहीं देता जो आपने माँगा, या TLS पर सहमति नहीं बन सकी। Signal Lab प्रमाणपत्र उसी तरह जाँचता है जैसे सिस्टम जाँचता है और जाँच छोड़ने का कोई स्विच नहीं है। HTTPS और WSS वही प्रमाणपत्र भरोसेमंद मानते हैं: उस ऑपरेटिंग सिस्टम के जहाँ इंजन चलता है — Windows पर Windows प्रमाणपत्र स्टोर, Linux और सर्वर इमेज पर सिस्टम के CA प्रमाणपत्र। स्व-हस्ताक्षरित प्रमाणपत्र या अपने CA के लिए, उसे उस मशीन के भरोसेमंद प्रमाणपत्रों में जोड़ें (सर्वर इमेज के लिए, उस पर बनी एक इमेज जो प्रमाणपत्र जोड़ती है), और उसी नाम से कनेक्ट करें जो प्रमाणपत्र देता है।

कोई सीक्रेट गायब है

secret.missing: कोई प्रयोग {{secret.NAME}} उपयोग करता है और जहाँ वह चलता है वहाँ उस नाम के अंतर्गत कोई मान सहेजा नहीं है।

• Windows पर डेस्कटॉप ऐप: इसे एडिटर के पैरामीटर में सीक्रेट के नीचे सेट करें। यह Windows Credential Manager में रहता है, इसलिए नई मशीन पर उसे फिर सेट करना पड़ता है।
• सर्वर: मान को फ़ाइल /run/secrets/signallab/NAME में (या --secrets-dir द्वारा बताए फ़ोल्डर में) या एनवायरनमेंट वैरिएबल SIGNALLAB_SECRET_NAME में डालें। सर्वर पेज से सीक्रेट सेट नहीं कर सकता (secret.read_only)।
• Linux पर डेस्कटॉप ऐप के पास सीक्रेट का कोई स्टोर नहीं है (secret.unsupported)। ऐसा प्रयोग signallab run के साथ चलाएँ, जो सीक्रेट फ़ाइलों और वैरिएबल से पढ़ता है, या किसी सर्वर पर।

देखें फ़ाइलें।

रन पाँच मिनट बाद रुक जाता है

300 सेकंड से अधिक लेने वाला रन run.timeout के साथ विफल होता है; किसी रन का यह अधिकतम समय है। छोटी सीमा API (/api/run का timeout) या कमांड लाइन (signallab run --timeout) के ज़रिए रन को दी जा सकती है।

ऐप अपडेट नहीं होता

• जब तक दिन में एक बार जाँचें चालू है, डेस्कटॉप ऐप दिन में एक बार नया संस्करण खोजता है, और जब आप Signal Lab के बारे में में अपडेट जाँचें दबाते हैं।
• यह पहले स्टूडियो के हब से पूछता है और जब हब तक न पहुँचा जा सके तो GitHub से। जब कोई नेटवर्क दोनों को रोक दे, तो अपडेट जाँचें अपडेट की जाँच नहीं हो सकी देता है; दैनिक खोज बिना कुछ कहे विफल हो जाती है।
• इसे केवल प्रकाशित रिलीज़ दी जाती हैं, कभी ड्राफ़्ट या pre-release नहीं।
• नई रिलीज़ ऐप तक तब पहुँचती है जब हब उसे देता है, जो GitHub पर आने के कुछ समय बाद हो सकता है: हब एक रिलीज़ को एक बार में कुछ इंस्टॉल तक पहुँचाता है।
• यह तभी इंस्टॉल करता है जब आप इंस्टॉल और रीस्टार्ट करें दबाते हैं — पहले चल रहे जॉब रोक दिए जाते हैं — और तभी जब रिलीज़ का हस्ताक्षर सही निकले: वरना अपडेट इंस्टॉल नहीं हुआ।
• सर्वर अपनी इमेज के साथ अपडेट होता है: उसकी compose फ़ाइल वाले फ़ोल्डर में docker compose pull && docker compose up -d.

लॉग कहाँ हैं

• डेस्कटॉप ऐप: यह कोई लॉग फ़ाइल नहीं लिखता। निचले पैनल में कंसोल टैब बताता है कि हर टूल ने क्या किया और क्या ग़लत हुआ, और डेवलपर्स को लिखें उसे डेवलपर्स को भेजे संदेश के साथ जोड़ देता है (इस कंप्यूटर का नाम, उसका पता या आपके फ़ोल्डर के बिना)। हर रन की रिपोर्ट डेटा फ़ोल्डर के runs/ में है।
• सर्वर: यह अपने standard output और error पर लॉग करता है — Docker में docker logs signallab. हर जॉब का शुरू होना, उसे माँगने वाले क्लाइंट के पते के साथ, लॉग होता है। --log (या SIGNALLAB_LOG) स्तर तय करता है: error, warn, info (डिफ़ॉल्ट) या debug; --log-format json (या SIGNALLAB_LOG_FORMAT) हर पंक्ति पर एक JSON ऑब्जेक्ट लिखता है।
• कमांड लाइन: signallab अपने संदेश अपने error output पर लिखता है; देखें कमांड लाइन।