नवीन VPN शॉर्टकट का गमावलेल्या सेटिंग्ज परत आणत नाही

गहाळ मेनू नोंदी आणि गायब होणाऱ्या प्राधान्ये एकाच प्रतिक्रियेने दुरुस्त होतात, पण या असंबंधित समस्या आहेत। एक डेस्कटॉप एकत्रीकरण आहे, दुसरी अनुप्रयोगाची स्थिती आहे, आणि नवीन चिन्ह स्वतः कोणतेही बदलत नाही। दोन्हींचे विभाजन करण्यासाठी एक प्रयोग पुरतो आणि लोक या विषयावर आणतात ती बहुतेक गोंधळाची स्पष्टता होते। लाँचर प्रोग्राम सुरू करतो; प्रोग्राम काय लक्षात ठेवायचे ते ठरवतो।

फक्त एकासारखी दिसणारी दोन कामे

डेस्कटॉप एकत्रीकरण म्हणजे वातावरण एक्झिक्युटेबल शोधू शकते, नाव आणि चिन्ह दाखवू शकते आणि योग्य युक्तिवाद पाठवू शकते। अनुप्रयोगाची स्थिती म्हणजे प्रोग्राम टिकाऊ जागी प्रोफाइल लिहितो आणि पुढील वेळी सुरू होताना ते पुन्हा वाचतो। एकही दुसऱ्याला अनिवार्य करत नाही, म्हणून कार्यरत शॉर्टकट सर्व विसरलेला क्लायंट सुरू करू शकतो।

अनुप्रयोगाच्या स्वतःच्या नियंत्रणांद्वारे एक निरुपद्रवी प्रदर्शन-प्राधान्य बदला, नंतर तो त्याच पद्धतीने बंद करून पुन्हा उघडा। प्राधान्य परत आले तर साठवणूक कार्यरत आहे आणि उर्वरित तक्रार डेटा साठवण्याबद्दल नाही तर विंडो शोधण्याबद्दल आहे। ते गायब झाले तर शॉर्टकट लक्ष विचलित करणारा आहे आणि खरा प्रश्न असा आहे की ती प्रक्रिया तिच्या फाइली कुठे ठेवते। एका वेळी एक प्राधान्य तपासा, कारण पुन्हा पासवर्ड मागणारा क्लायंट संरचना गमावण्याऐवजी एखादे रहस्य संरक्षित करत असेल।

पुन्हा प्रतिष्ठापन करण्यापूर्वी सुरुवातीचे इनपुट तुलना करा

डेस्कटॉप नोंदीपासून सुरुवात करा आणि ती प्रत्यक्षात काय करते ते वाचा, कारण मेनूमधून सुरू करणे स्वयंचलितपणे टर्मिनलमधून सुरू करण्यासारखेच प्रक्रिया-वातावरण नसते। महत्त्वाच्या किल्ल्या आहेत Exec, Path आणि अप्रत्यक्षपणे सत्र जे वातावरण देते ते। Exec मधील रॅपर स्क्रिप्ट चल सेट करू शकते, डिरेक्टरी बदलू शकते किंवा मेनू कधीही न दाखवणारा विशेषाधिकारप्राप्त सहाय्यक बोलावू शकते। पुन्हा प्रतिष्ठापन करणे अनुप्रयोगाकडे आधीच असलेल्या फाइली बदलते, आणि हे क्वचितच बदललेले चल असते।

grep -h '^Exec=' ~/.local/share/applications/*.desktop
desktop-file-validate ~/.local/share/applications/client.desktop

~/.local/share/applications अंतर्गत फाइल /usr/share/applications मधील फाइलीपूर्वी पाहा, कारण वापरकर्त्याची प्रत प्रणालीच्या प्रतीवर सावली टाकते। नोंदीचे वर्तन चुकीचे असल्यास desktop-file-validate चालवा आणि काढलेल्या मार्गाकडे अजूनही निर्देश करणारी जुनी प्रत शोधा। अवैध वापरकर्ता प्रतीला बहुतेक डेस्कटॉप अजूनही प्राधान्य देतात, त्यामुळे खराब फाइल मेनूमधून नोंद काढू शकते तर पॅकेजची फाइल वैध राहते। नंतर तोच आदेश हाताने चालवा आणि दोन सुरुवाती काय उत्पन्न करतात याची तुलना करा।

प्राधान्य प्रत्यक्षात कुठे राहते

XDG आधार डिरेक्टरी नियम पाळणारे अनुप्रयोग संरचना $XDG_CONFIG_HOME अंतर्गत, टिकाऊ स्थिती $XDG_STATE_HOME अंतर्गत आणि विल्हेवाट लावण्यायोग्य डेटा $XDG_CACHE_HOME अंतर्गत ठेवतात, आणि ते चल सेट नसल्यास मूलभूतपणे ~/.config, ~/.local/state आणि ~/.cache वापरतात। हे तीन भूमिका आहेत, वचने नाहीत, म्हणून एखादे विशिष्ट VPN उत्पादन पूर्णपणे वेगळे काही दस्तऐवजीकरण करू शकते। डिरेक्टरीच्या नावावरून मार्ग अंदाजण्यापेक्षा विक्रेत्याचे स्वतःचे दस्तऐवज वाचणे चांगले। दस्तऐवज कमी असल्यास फाइलप्रणालीऐवजी प्रक्रियेचे निरीक्षण करा।

फाइल उघडण्यावर गाळलेला ट्रेस क्लायंट जो प्रत्येक संरचना मार्ग अजमावतो तो दाखवतो, बाहेर पडताना तो जो मार्ग लिहितो त्यासह। तोच वापरकर्ता आणि तेच वातावरण यासह चालवा, नंतर ते मार्ग तुम्ही अपेक्षित असलेल्या डिरेक्टरींशी तुलना करा।

strace -f -e trace=openat,stat -o /tmp/vpn.log vpn-client

रहस्ये आणि प्रोफाइलचे मालक वेगळे

साठवलेले प्रोफाइल आणि साठवलेले ओळखपत्र वेगवेगळ्या वस्तू आहेत, अनेकदा वेगळ्या साठ्यासह। एक संरचना फाइलमध्ये राहू शकते तर दुसरे प्रत्येक सत्राला उघडणाऱ्या कीरिंगमध्ये बसते, त्यामुळे पुन्हा पासवर्ड मागणारा क्लायंट कदाचित ज्यासाठी तयार केला तेच करत असेल। विनंती थांबवण्यासाठी प्रोफाइल हटवणे हाच मार्ग लोक कार्यरत संरचना गमावतात।

विशेषाधिकारप्राप्त सुरुवाती हे अधिक गुंतागुंतीचे करतात, कारण sudo किंवा PolicyKit सहाय्यकाद्वारे सुरू करणे वेगळी होम डिरेक्टरी आणि त्यामुळे वेगळा संरचना संच सादर करू शकते। संपूर्ण होम डिरेक्टरीवर आवर्तनाने नाही, तर अनुप्रयोग दस्तऐवजीकरण करतो त्या विशिष्ट फाइलवर मालकी दुरुस्त करा, नंतर पुढे प्रोफाइल कोणत्या ओळखीकडे असावे ते ठरवा आणि भविष्यातील सुरुवाती त्याच्याशी सुसंगत ठेवा।

चिन्ह तुम्हाला काय सांगू शकते आणि काय नाही

चिन्ह सिद्ध करते की लाँचर फाइल सोडवली जाते, आणि त्यापेक्षा जास्त काही नाही। कनेक्शनची स्थिती क्लायंटची आहे, त्यामुळे एकमेव विश्वासार्ह तपासणी म्हणजे इंटरफेस, मार्ग किंवा क्लायंटचे स्वतःचे स्थिती आउटपुट। सुरू न झालेले ट्रे अ‍ॅपलेट कार्यरत टनेल तुटलेले दाखवू शकते, तर जुने अ‍ॅपलेट तुटलेले ठीक दाखवू शकते। कनेक्शन आणि लाँचर स्वतंत्रपणे तपासा, नंतर तुम्ही प्रत्यक्षात कोणते दुरुस्त केले ते लिहा।

दोन्ही तुटलेले असल्यास, दुरुस्ती एकच बदल मानण्याच्या प्रवृत्तीला प्रतिकार करा। नोंद दुरुस्त करा, सुरुवातीची खात्री करा, नंतर टनेलची खात्री करा आणि प्रत्येक पायरीचा निकाल नोंदवा। तीच नोंद पुढील गमावलेल्या सेटिंग्जच्या अहवालाला याची पुनरावृत्ती नाही तर निदानयोग्य बनवते, आणि तीच पुढील व्यक्तीला सांगते की समस्येचा कोणता अर्धा भाग खरा होता।