apt purge VPNని తొలగించింది, కానీ సేవ బూట్ సమయంలో ఇప్పటికీ ప్రారంభమవుతుంది
apt purge ప్యాకేజీ ఫైళ్లను తొలగిస్తుంది, విక్రేత స్క్రిప్ట్ ఇన్స్టాల్ చేసిన unit కాదు. unit మరియు దాని wants లింక్ను తొలగించి, తర్వాత బూట్ యొక్క ఒకే యజమానిని ఎంచుకోండి.
apt purge ప్యాకేజీ పోయిందని చెబుతుంది, అయినా ప్రతి ప్రారంభంలో టన్నెల్ మళ్లీ పైకి వస్తుంది. journal పెరుగుతూనే ఉంటుంది, మార్గాలు తిరిగి వస్తాయి, మరియు యంత్రం ఏదీ తొలగించనట్లే ప్రవర్తిస్తుంది. విక్రేత ఇన్స్టాలర్ ప్యాకేజీ నిర్వాహకుడు ఎప్పుడూ నమోదు చేయని ఫైళ్లను రాయగలదు, కాబట్టి ప్యాకేజీని తొలగించడం మరియు ఉత్పత్తిని తొలగించడం రెండు వేర్వేరు పనులు. కింది runbook రెండు నమోదులను వేరు చేసి తొలగింపును ఉద్దేశపూర్వకంగా పూర్తి చేస్తుంది.
రెండు ఇన్స్టాలర్లు, రెండు వేర్వేరు నమోదులు
Debian ప్యాకేజీలు ఫైల్ జాబితాను ఉంచుకుంటాయి, purge ఆ జాబితా పేర్కొన్నదాన్ని మరియు ప్యాకేజీ కాన్ఫిగరేషన్ను మాత్రమే తొలగిస్తుంది. shell ఇన్స్టాలర్ లేదా .run బండిల్ అలాంటి జాబితాను ఉంచుకోదు; అది ఇష్టమైన చోట రాస్తుంది, సాధారణంగా /opt, /usr/local మరియు /etc/systemd/system లో. ఆ మార్గాలలో ఏదీ ఏ ప్యాకేజీ ఫైల్ జాబితాలో కనిపించదు, కాబట్టి dpkg వాటిని తెలియదు, నివేదించదు. చివరికి ఒకే ఫైల్ సిస్టమ్పై రెండు ఇన్స్టాలేషన్ యజమానులు ఉంటారు, వారిలో ఒకరు మాత్రమే లెక్క ఉంచుతారు.
తొలగించే ముందు ఆ నిర్దిష్ట మార్గం గురించి dpkgని అడగండి. అది నిరాకరించే మార్గం మీరు తొలగించాల్సినది, అదే సమాధానం తర్వాతి అప్గ్రేడ్ దాన్ని తిరిగి తెస్తుందా అని కూడా చెబుతుంది.
dpkg -S /etc/systemd/system/acmevpn.service
systemctl list-unit-files | grep -i acmevpn
unit మరియు దాని wants లింక్ వేర్వేరు ఫైళ్లు
ప్రారంభించడం అనేది ఇన్స్టాల్ చేయడం నుండి వేరైన చర్య. unit తన [Install] విభాగంలో లక్ష్య సంబంధాలను ప్రకటిస్తుంది, systemctl enable ఆ ప్రకటనలను ప్రతి లక్ష్యం యొక్క .wants/ డైరెక్టరీలో చిహ్న లింకులుగా మారుస్తుంది. ఇప్పుడు రెండు మార్గాలున్నాయి: unit ఫైల్, మరియు దాన్ని బూట్ లక్ష్యంలోకి లాగే లింక్. ఫైల్ను మాత్రమే తొలగిస్తే లింక్ ఎక్కడికీ చూపదు, ఇది బూట్లో ఫిర్యాదును కలిగిస్తుంది; లింక్ను మాత్రమే తొలగిస్తే unit పేరుతో ప్రారంభించగలిగేలా ఉంటుంది. రెండూ పోవాలి.
వాటిని క్రమంగా తీసివేసి తర్వాత మళ్లీ లోడ్ చేయండి, systemd పాత నిర్వచనాలను మెమరీలో ఉంచడం ఆపడానికి.
systemctl disable --now acmevpn.service
systemctl show -p FragmentPath -p ExecStart acmevpn.service
sudo rm /etc/systemd/system/acmevpn.service
sudo rm /etc/systemd/system/multi-user.target.wants/acmevpn.service
systemctl daemon-reload
స్థానాన్ని ఊహించకుండా FragmentPath చదవండి, ఎందుకంటే విక్రేత /etcకు బదులు /usr/lib/systemd/system లేదా /lib/systemd/systemలో రాసి ఉండవచ్చు. ఆశించిన కాపీని తొలగిస్తే ప్రభావవంతమైనది నడుస్తూనే ఉంటుంది, మరియు తదుపరి రీలోడ్ వరకు సవరణ విజయవంతంగా కనిపిస్తుంది. రీలోడ్ ముగిసిన తర్వాత unit ఫైళ్లను మళ్లీ జాబితా చేసి, పేరు ఇక కనిపించదని నిర్ధారించండి.
ఈ అమరికను సజీవంగా ఉంచే బైనరీని కనుగొనండి
ప్రారంభించిన unit ప్యాకేజీ డేటాబేస్ ఏమనుకున్నా డీమన్ను ప్రారంభిస్తూనే ఉంటుంది. ఆ ప్రక్రియ టన్నెల్ను తిరిగి తెస్తుంది, మార్గాలను మళ్లీ చేరుస్తుంది లేదా kill-switch నియమాన్ని పునరుద్ధరిస్తుంది, మరియు అమరికను పరిశీలించే వరకు ప్రవర్తన అతీతంగా కనిపిస్తుంది. ExecStart మార్గాన్ని అనుసరించి బైనరీ ఇంకా ఉందా చూడండి, ఎందుకంటే /opt కింద మిగిలిన అమలయ్యే ఫైల్ ఈ అమరికకు అవసరమైనదంతా. unitను తొలగిస్తే షెడ్యూల్ చేసిన ప్రారంభం ఆగుతుంది; అది ప్రోగ్రామ్ను తొలగించదు.
స్థితి డైరెక్టరీలను కూడా అదే శ్రద్ధతో చూడండి. ఖాతా టోకెన్లు, సృష్టించిన ప్రొఫైల్లు మరియు కాష్ చేసిన సర్వర్ జాబితాలు /var/lib కింద లేదా హోమ్ డైరెక్టరీలో నివసిస్తాయి, అవి ఆధారాలు, పారేయగల కాష్ కాదు. సేవ ఆగిన తర్వాత వాటిని ఉద్దేశపూర్వకంగా తొలగించి, ఏమి తీసుకున్నారో రాయండి.
sudo ls -l /opt/acmevpn /usr/local/bin/acmevpn
sudo find /var/lib -maxdepth 2 -iname "*acme*"
systemctl is-enabled acmevpn.service
బూట్ యొక్క ఒకే యజమానిని ఎంచుకుని పరీక్షించండి
మూడు అభ్యర్థులు బూట్పై దావా వేయగలరు, మూడింటినీ ఇన్స్టాల్ చేస్తే రెట్టింపు రక్షణకు బదులు పోటీ ఏర్పడుతుంది. డెస్క్టాప్ ఆటోస్టార్ట్ ఫైల్ ఎవరైనా సైన్ ఇన్ చేసిన తర్వాతే నడుస్తుంది, systemd unit ముందుగా నడుస్తుంది కానీ స్క్రీన్ లేకుండా పనిచేసే క్లయింట్ కావాలి, మరియు cron @reboot ఎంట్రీ నెట్వర్క్ క్లయింట్కు తప్పు కావచ్చిన షెడ్యూల్ ప్రకారం మండుతుంది. విక్రేత CLI అదనంగా సర్వర్ ఆర్గ్యుమెంట్ అడగవచ్చు, ఎందుకంటే బూట్లో కొనసాగించడానికి మునుపటి సెషన్ ఉండదు. క్లయింట్ ఎలా ప్రామాణీకరిస్తుందో దానికి సరిపోయే అభ్యర్థిని ఎంచుకోండి, మిగతావాటిని వదిలేయండి.
యంత్రాన్ని మళ్లీ బూట్ చేసి మూడు స్వతంత్ర వాస్తవాలను చూసి పరీక్షించండి: unit స్థితి, ప్రక్రియల జాబితా, మరియు మీరు ధృవీకరించగల ఏదో ఒకదానికి కొత్త కనెక్షన్. కీరింగ్ లేదా ఇంటరాక్టివ్ లాగిన్ అవసరమైన క్లయింట్ సరైన unit ఫైల్తో కూడా బూట్లో విఫలమవుతుంది, మరియు సేవా స్థితి మాత్రమే కాకుండా journal చదివితే అది అలా చెబుతుంది.
గానీ క్లయింట్కు ప్రశ్న లేకుండా పనిచేసే ఆధారాన్ని ఇవ్వండి, లేదా సైన్ ఇన్లో దాన్ని ప్రారంభించండి. రెండూ సమర్థనీయం, మరియు రెండింటినీ కలపడమే ఒక టన్నెల్కు దాని కోసం పోరాడే ఇద్దరు యజమానులను తెచ్చే మార్గం.
తదుపరి purge ఏమి ఆశించాలో రాయండి
ఏదైనా చేతితో తొలగించిన తర్వాత రెండు వాస్తవాలను నమోదు చేయండి: ఏ ఇన్స్టాలర్ ఈ అమరికను సృష్టించింది, ఇప్పుడు ఏ యజమాని దాన్ని ప్రారంభిస్తున్నారు. ఆ గమనిక తదుపరి purgeను ఆశ్చర్యం నుండి తనిఖీ జాబితాలోని అంశంగా మారుస్తుంది, మరియు పని చేసిన వ్యక్తి కంటే ఎక్కువ కాలం జీవిస్తుంది.
దాన్ని వ్యక్తిగత డైరెక్టరీలో కాకుండా సేవా కాన్ఫిగరేషన్ పక్కన ఉంచి తేదీ పెట్టండి, ఎందుకంటే విక్రేత అప్డేట్ మీరు తొలగించిన unitను పునరుద్ధరించవచ్చు. కొన్ని నెలలకోసారి systemctl list-unit-filesను ఆ గమనికతో పోల్చడం సవరణ ఇంకా చవకగా ఉన్నప్పుడే పునరుద్ధరణను పట్టుకుంటుంది.