VPN సేవ EXEC వద్ద విఫలమవుతుంది: unit, binary మరియు sudoers పోల్చండి
EXEC దశలో విఫలం అంటే systemd binary ను ప్రారంభించలేకపోయింది. ఏదైనా మార్చే ముందు unit పాత, ఇన్‌స్టాల్ చేసిన పాత మరియు sudoers అనుమతిని పోల్చండి.
నిన్న టన్నెల్ పనిచేసింది, ఈ ఉదయం unit చనిపోయింది, journal లో Failed at step EXEC spawning /usr/local/bin/vpnclient ఉంది. ఆధారాలు, మార్గాలు మరియు ఖాతా ఆ వాక్యంలో ఎప్పుడూ రావు. systemd ExecStart ను ఒక మార్గంగా పరిష్కరించింది, దాన్ని అమలు చేయమని కెర్నల్‌ను కోరింది, కెర్నల్ నిరాకరించింది, ఎక్కువగా ఆ మార్గంలో ఏమీ లేకపోవడం లేదా ఫైల్ అమలు చేయలేని స్థితిలో ఉండటం వల్ల. విశ్లేషించిన ఆదేశం వ్యతిరేకాన్ని నిరూపించే వరకు ఈ లోపాన్ని ఫైల్ మరియు argv సమస్యగా పరిగణించండి.
ప్రామాణీకరణ ప్రారంభం కాకముందే EXEC ఎందుకు విఫలమవుతుంది
systemd ExecStart ను shell ద్వారా అమలు చేయదు. అది fork చేస్తుంది, లైన్ నుండి ఆర్గ్యుమెంట్ వెక్టర్‌ను నిర్మిస్తుంది, మొదటి మూలకంపై execve ను పిలుస్తుంది. ఆ పిలుపు విఫలమైతే, సేవ ఎప్పటికీ VPN క్లయింట్ యొక్క సొంత కోడ్‌ను చేరుకోదు, కాబట్టి ప్రొఫైల్ సవరణ లేదా ఆధారాల తనిఖీ సహాయపడదు.
స్థితి కోడ్ ఈ కుటుంబాన్ని సాధారణ క్రాష్‌ల నుండి వేరు చేస్తుంది. status=203/EXEC తో బయటకు వెళ్లే unit ఎప్పుడూ ప్రక్రియను ప్రారంభించలేదు; ప్రారంభమై తర్వాత status=1 తో బయటకు వెళ్లే unit ప్రామాణీకరణ, DNS లేదా మార్గనిర్దేశనంలో విఫలమై ఉండవచ్చు. క్లయింట్ లాగ్ చదవడానికి ముందు కోడ్ చదవండి, ఎందుకంటే మొదటి సందర్భంలో క్లయింట్ లాగ్ ఖాళీగా ఉంటుంది.
journal లోని మార్గం systemd ఉపయోగించినది, మీరు సవరించినది కావాల్సిన అవసరం లేదు. Drop-in ఫైళ్లు మరియు జనరేటర్ అవుట్‌పుట్ విక్రేత ఫైల్‌ను అధిగమించవచ్చు, పాత daemon-reload పాత లైన్‌ను మెమరీలో ఉంచుతుంది. అందుకే మొదటి నిర్ధారణ మీకు గుర్తున్న మార్చిన ఫైల్ తెరవడం కాదు, systemd ను ఆదేశాన్ని ఏమని భావిస్తుందో అడగడం.
binary మార్గం వ్రాయబడే మూడు స్థలాలు
పంపిణీ ప్యాకేజీ, విక్రేత స్క్రిప్ట్ మరియు విడుదల tarball నుండి ఇన్‌స్టాల్ చేసిన VPN క్లయింట్ మూడు వేర్వేరు ప్రిఫిక్స్‌లలో పడవచ్చు. unit, ప్రత్యేక హక్కు నియమం మరియు ఇన్‌స్టాలర్ ప్రతి ఒకటి ఆ ప్రిఫిక్స్‌లలో ఒకదాన్ని నమోదు చేశాయి, మూడింటిలో రెండు సరిపోలనప్పుడు లోపం కనిపిస్తుంది.
| Record | Common value | How to read it |
|---|---|---|
| Unit or drop-in | /usr/local/bin/vpnclient | systemctl cat vpnclient.service |
| Installed binary | /usr/bin/vpnclient | command -v vpnclient, then ls -l the result |
| Sudoers grant | /opt/vpnclient/bin/vpnclient | sudo grep -r vpnclient /etc/sudoers.d/ |
నిర్దిష్ట అసమానత ఇలా కనిపిస్తుంది: విక్రేత స్క్రిప్ట్ /usr/local/bin లో ఇన్‌స్టాల్ చేస్తుంది, tarball /opt క్రింద తెరవబడింది, unit ఇంకా మునుపటి ప్యాకేజీ యొక్క పాత /usr/bin మార్గాన్ని పేర్కొంటోంది. ఆ ఫైళ్లలో ఒకటి మాత్రమే ఉంది, మరియు అది అరుదుగా ExecStart లోని ఫైల్.
ఏదైనా ఫైల్ మార్చే ముందు ఏ మార్గం కానానికల్ అని నిర్ణయించండి. binary పంపిణీ ప్యాకేజీకి చెందితే, ప్యాకేజీ మార్గం కానానికల్, unit దాన్ని అనుసరించాలి. విక్రేత స్క్రిప్ట్‌కు చెందితే, అదే నియమం విక్రేత ప్రిఫిక్స్‌కు వర్తిస్తుంది. ప్రిఫిక్స్‌ల మధ్య binary ను కాపీ చేయడం తదుపరి అప్‌గ్రేడ్‌లో వేరుపడే రెండు కాపీలను సృష్టిస్తుంది.
కోట్‌లోని ఆదేశం ఫైల్ పేరు అయినప్పుడు
రెండవ విఫలత విధానం అదే journal లైన్ వెనుక దాగి ఉంది. ఎవరో దీన్ని unit లో రాసి, బూట్ సమయంలో క్లయింట్ కనెక్ట్ అవుతుందని ఆశిస్తారు:
ExecStart=/usr/bin/"vpnclient connect office"systemd విలువను పదాలుగా విభజిస్తుంది, కాబట్టి మొదటి పదం /usr/bin/vpnclient connect office అవుతుంది, కోట్లు సమూహ సింటాక్స్‌గా తొలగించబడతాయి. తర్వాత కెర్నల్ పేరులో ఖాళీలు ఉన్న ఫైల్ కోసం వెతుకుతుంది, అలాంటిది లేదు. binary ఇన్‌స్టాల్ అయి ఉన్నా లోపం లేని binary లాంటిదే.
మద్దతు ఉన్న రూపం నిజమైన అమలు చేయగల ఫైల్, తర్వాత వేర్వేరు ఆర్గ్యుమెంట్లు, ఉదాహరణకు ExecStart=/usr/bin/vpnclient connect office. పని ప్రవాహానికి నిజంగా పైప్‌లైన్ లేదా గొలుసు అవసరమైతే, దాన్ని స్క్రిప్ట్‌లో పెట్టి స్క్రిప్ట్‌ను పిలవండి, ఎందుకంటే ExecStart లో && లేదు, పైపులు లేవు, glob విస్తరణ లేదు.
ఫైల్ సిస్టమ్ కాదు, unit సరిచేయండి
ఆకర్షణీయమైన పరిష్కారం ఆశించిన మార్గం నుండి నిజమైన binary కు సింబాలిక్ లింక్. ప్యాకేజీ అప్‌డేట్ అయి లింక్ తొలగించిన ఫైల్ వైపు చూపే వరకు, లేదా SELinux లేబుల్ లక్ష్యంతో సరిపోలకుండా అయ్యే వరకు అది పనిచేస్తుంది. unit ను drop-in ద్వారా సవరించడం మంచిది, అప్పుడు విక్రేత ఫైల్ తాకబడకుండా ఉంటుంది, అప్‌గ్రేడ్‌లు ఊహించదగినవిగా ఉంటాయి.
ప్రత్యేక హక్కు నియమం అదే మార్గానికి మరియు అదే ఉప ఆదేశాలకు సరిపోలాలి. /usr/local/bin/vpnclient కోసం sudoers నమోదు /usr/bin/vpnclient కు అధికారం ఇవ్వదు, ప్రతి ఆర్గ్యుమెంట్‌ను అనుమతించే నమోదు ఏదైనా స్థానిక ప్రక్రియను టన్నెల్‌ను మళ్లీ కాన్ఫిగర్ చేయడానికి లేదా ఆపడానికి అనుమతిస్తుంది. unit కు అవసరమైన రెండు చర్యలను ఇవ్వండి, సేవను ఆపడం ఇంటర్‌ఫేస్‌ను ఇప్పటికే మూసివేస్తే విడదీయడాన్ని దాని వెలుపల ఉంచండి.
ఇక్కడే పోలిక ఫలితం ఇస్తుంది: unit, ప్యాకేజీ డేటాబేస్ మరియు sudoers అన్నీ ఒకే మార్గాన్ని పేర్కొనాలి. అలా జరిగితే, రీబూట్ లేకుండా మరియు మూడవ స్థలంలో binary కాపీ లేకుండా EXEC లోపం మాయమవుతుంది.
రీస్టార్ట్ ముందు విశ్లేషించిన ఆదేశాన్ని నిరూపించండి
sudo systemctl daemon-reload
sudo systemctl cat vpnclient.service
systemctl show -p ExecStart vpnclient.service
systemd-analyze verify /etc/systemd/system/vpnclient.service
sudo systemctl restart vpnclient.service
systemctl status vpnclient.service --no-pagersystemctl show నిర్ణాయక అవుట్‌పుట్, ఎందుకంటే systemd నిజంగా విశ్లేషించిన argv ను, ఏదైనా drop-in తో సహా ముద్రిస్తుంది. systemd-analyze verify మీరు రీస్టార్ట్ చేసే ముందు లేని లేదా అమలు చేయలేని మార్గాన్ని పట్టుకుంటుంది, రీస్టార్ట్ తర్వాత status ఆదేశం ప్రక్రియ ఇప్పుడు ఉందో లేదో చెబుతుంది.
unit ప్రారంభమై తర్వాత విఫలమైతే, మీరు EXEC కుటుంబాన్ని విడిచి క్లయింట్ యొక్క సొంత లోప నిర్వహణలోకి ప్రవేశించారు. journal లో క్లయింట్ సందేశాన్ని వెతకండి, మరో execve విఫలతను కాదు. unit diff మరియు sudoers diff ను మార్పు రికార్డులో కలిసి ఉంచండి, తదుపరి అప్‌గ్రేడ్ విభజిత మార్గాన్ని నిశ్శబ్దంగా తిరిగి తీసుకురాకుండా.