VPN యూనిట్ నెట్‌వర్క్‌కు ముందే ఎందుకు ప్రారంభమై తర్వాత చనిపోతుంది

మెషీన్‌ను బూట్ చేయండి, లాగిన్ అవ్వండి, మరియు టన్నెల్ పైకి వచ్చి కొన్ని సెకన్ల తర్వాత చనిపోయినట్లు తెలుసుకోండి. ప్రొఫైల్ బాగానే ఉంది, సర్టిఫికెట్ బాగానే ఉంది, మిగిలిన ఏకైక ఆనవాలు ఆ బూట్ జర్నల్. సాధారణంగా జరిగింది ఒక పోటీ: మెషీన్‌కు చిరునామా రాకముందే యూనిట్ ప్రారంభమైంది, మరియు అది ప్రకటించిన క్రమం కనిపించే అర్థాన్ని ఇవ్వలేదు. క్రింద ఉన్నదంతా ఆ పోటీని సాక్ష్యాల నుండి నిరూపించడం మరియు దాన్ని సరిగ్గా మూసివేయడం గురించి.

లక్ష్యం కలిసే స్థలం, నిర్వాహకుడు కాదు

network-online.target కు నెట్‌వర్క్ అంటే ఏమిటో తెలియదు. ఇది ఒక సమన్వయ బిందువు, లింక్ ఉపయోగించగలిగే వరకు ప్రారంభాన్ని ఆలస్యం చేయాల్సిన సేవను ఇది సేకరిస్తుంది, మరియు నిర్వచనాన్ని మెషీన్‌ను కలిగి ఉన్న నెట్‌వర్క్ మేనేజర్‌కు అప్పగిస్తుంది. చాలా డెస్క్‌టాప్‌లు మరియు సర్వర్లలో దీని అర్థం NetworkManager లేదా systemd-networkd అందించే నిరీక్షణ సేవ. ఏదీ సక్రియం చేయకపోతే లక్ష్యానికి నిరీక్షించడానికి ఏమీ ఉండదు, కాబట్టి ఏదో దాన్ని లాగిన క్షణంలోనే అది పూర్తవుతుంది, మరియు అది DHCP సమాధానం ఇవ్వడానికి చాలా ముందే జరగవచ్చు. మీ యూనిట్‌లోని క్రమ వరుస నిజాయితీగా ఉంది, అయినా నిష్ప్రయోజనం.

కాబట్టి మొదటి ప్రశ్న మీ యూనిట్ ఏమి ప్రకటిస్తుందనేది కాదు. ఈ మెషీన్‌లో ఏదైనా నిజంగా నిరీక్షణ చేస్తోందా అనేది.

యూనిట్ ఫైల్‌కు బదులు చివరి బూట్ చదవండి

యూనిట్ ఫైళ్లు ఉద్దేశాన్ని వివరిస్తాయి, జర్నల్ ఏం జరిగిందో వివరిస్తుంది. ఆ బూట్‌ను మాత్రమే అడగండి, మోనోటోనిక్ టైమ్‌స్టాంపులతో, ప్రతి సందేశం ఒకే గడియారంలో కూర్చునేలా. తర్వాత రెండు వరుసలు కనుగొనండి: టన్నెల్ యూనిట్ ప్రారంభం కావడం మొదలైన క్షణం, మరియు చిరునామా కనిపించిన లేదా నిరీక్షణ సేవ ముగిసిన క్షణం. ఆ రెండు సంఖ్యలను క్రమపరచండి, పోటీ నిర్ధారించబడుతుంది లేదా మినహాయించబడుతుంది.

ఆధారత దృశ్యం దీన్ని నిర్ధారిస్తుంది. టన్నెల్ యూనిట్ కోసం కీలక గొలుసులో నిరీక్షణ సేవ లేకపోతే, ఆ మార్గంలో ఏదీ ప్రారంభాన్ని ఆలస్యం చేయలేదు, మరియు లక్ష్యం మీరు ఊహించిన పని చేయలేదు. రెండు దృశ్యాలు, ఒక ముగింపు.

systemctl list-units --type=service --state=running | grep wait-online
journalctl -b -o short-monotonic -u openvpn-client@office

నిరీక్షణ జోడించండి, తర్వాత మళ్లీ ప్రయత్నం

ప్యాకేజీ చేసిన యూనిట్‌ను సవరించడం బదులు drop-in ఉపయోగించండి, ప్యాకేజీ నవీకరణ మార్పును నిశ్శబ్దంగా పడేయకుండా. రెండు ఆదేశాలు ముఖ్యం: యూనిట్ లక్ష్యం తర్వాత క్రమబద్ధం కావాలి, మరియు లక్ష్యాన్ని అదే లావాదేవీలోకి లాగాలి. క్రమం మాత్రమే లక్ష్యాన్ని పిలవదు; కోరిక అలా చేస్తుంది.

OpenVPN క్లయింట్ యొక్క ప్యాకేజీ చేసిన యూనిట్ ఇప్పటికే రెండింటినీ కలిగి ఉంది. చేతితో రాసిన యూనిట్లు సాధారణంగా ఒకటి లేదా ఏదీ కలిగి ఉండవు, ఏదైనా జోడించే ముందు దీన్ని తనిఖీ చేయడం విలువైనది.

[Service]
Restart=on-failure
RestartSec=15

స్థిర నిద్ర ఎందుకు ఉచ్చు

ExecStartPre లో నిద్ర క్రమ సవరణలా అనిపిస్తుంది మరియు అదనపు దశలతో ఆలస్యంలా ప్రవర్తిస్తుంది. ఆరోగ్యకరంగా ఉన్నవి సహా ప్రతి బూట్‌ను ఇది నెమ్మదిస్తుంది, మరియు మీరు ఎంచుకున్న సంఖ్య కంటే లింక్ ఎక్కువ సమయం తీసుకుంటే ఇప్పటికీ ఓడిపోతుంది.

అంతకంటే దారుణం, నిరీక్షణ సేవ పనిచేస్తోందా అనేది ఇది దాస్తుంది, కాబట్టి తదుపరి వైఫల్యం అదే సమస్య వేరే సమయంతో కాకుండా పూర్తిగా కొత్త సమస్యలా కనిపిస్తుంది. చిన్న పునఃప్రారంభ ఆలస్యం మంచి సాధనం: ఆరోగ్యకరమైన బూట్‌పై దానికి ఎటువంటి ఖర్చు ఉండదు మరియు ఓడిపోయిన పోటీని మరో ప్రయత్నంగా మారుస్తుంది. విరామాన్ని మితంగా ఉంచండి మరియు యూనిట్ విజయవంతం కావడానికి అనుమతించండి. అది శాశ్వతంగా పునఃప్రారంభమైతే, ప్రొఫైల్ పాడైంది మరియు ఎన్ని మళ్లీ ప్రయత్నాలు చేసినా అది మారదు, కాబట్టి విరామాన్ని పెంచే బదులు లాగ్ చదవండి.

క్రమం సరైనా పేర్లు ఇప్పటికీ విఫలమైనప్పుడు

టన్నెల్ మార్గంతో క్రియాశీల యూనిట్ అంటే క్రమం తన పని చేసింది మరియు మిగిలిన లోపం ఒక పొర పైన ఉంది. సాధారణ రూపం టన్నెల్ యొక్క up స్క్రిప్ట్ వర్తించే రిజాల్వర్ సెట్టింగ్, లింక్ లేదా రిజాల్వర్ దాన్ని నిలుపుకోవడానికి సిద్ధమవడానికి ముందే. వైఫల్య సమయంలో రిజాల్వర్ స్థితిని టన్నెల్ యూనిట్ పునఃప్రారంభించిన తర్వాత స్థితితో పోల్చండి.

పునఃప్రారంభం శోధనలను సరిచేస్తే, తప్పు DNS సర్వర్ కాదు, ప్రారంభ క్రమంలో లోపం ఉంది, మరియు ఆ రెండింటికీ వేర్వేరు సరిచేయడాలు కావాలి. తర్వాత సేవా పునఃప్రారంభం బదులు చల్లని బూట్‌తో మొత్తం నిరూపించండి, ఎందుకంటే పునఃప్రారంభం ఇప్పటికే పైకి ఉన్న నెట్‌వర్క్‌పై నడుస్తుంది మరియు మీరు వెంటాడుతున్న లోపాన్ని సరిగ్గా దాస్తుంది. లింక్‌ను ఉద్దేశపూర్వకంగా నెమ్మదిగా ఉంచి దీన్ని పునరావృతం చేయండి, మరియు నెట్‌వర్క్ వేగంగా ఉన్నప్పుడు మాత్రమే పనిచేసే యూనిట్‌ను ఇంకా పాడైనదిగా పరిగణించండి.