Кога стартерот одбива да го стартува OpenVPN затоа што веќе постои PID-датотека, природното читање е дека некаде работи тунел. Тоа читање е доволно често погрешно за да вреди да се провери пред ништо да се избрише. Датотека во директориум за извршување е книговодство, а книговодството ги преживува падовите, рестартирањата и прекинатите исклучувања што не оставиле процес. Два прашања го решаваат случајот: дали има жив процес и дали тој процес ѝ припаѓа на оваа инстанца.

Започнете со услугата, не со датотеката

Одбивањето обично доаѓа од стартер, а не од самиот OpenVPN. Тој чита патека, наоѓа нешто таму и запира пред да се анализира конфигурација. Првото прашање затоа е за договорот на стартерот, а не за тунелот.

Прочитајте ја единицата или скриптата што ја испечати пораката и забележете три работи: патеката што ја проверува, типот на услуга што го декларира и дали воопшто е одговорна за пишувањето на датотеката. Современа единица може да користи едноставен или notify надзор и никогаш да не допре PID-датотека, додека постара init-скрипта може сама да создаде една. Копирањето на проверка од еден модел во друг го произведува токму овој вид одбивање. Откријте кој модел се користи пред да протолкувате нешто.

Само тогаш прашањето станува дали некоја инстанца навистина работи.

Проверете дали тој идентификатор ѝ припаѓа на вашата инстанца

Број во датотека докажува дека е напишан број. Тој не докажува дека процес со тој идентификатор постои сега, и сигурно не докажува дека процесот е ваш, бидејќи идентификаторите се користат повторно по рестартирање.

Споредете го времето на стартување на процесот со временската ознака на датотеката, извршната датотека со командата на единицата и членството во услугата со името на единицата. Несовпаѓање во кое било од трите значи дека гледате книговодство, а не тунел.

На домаќин што извршува контејнери или неколку именски простори, идентификаторот може да има смисла во еден приказ, а да отсуствува во друг. Тоа што не гледате процес исто така не е доказ дека не постои, ако вашата сметка не може да го провери. Проверете од контекстот што го користи стартерот пред да донесете заклучоци.

systemctl status [email protected]
ps -o pid,lstart,args -p "$(cat /run/openvpn/vpn.pid)"

Што вети стартерот да направи со датотеката

PIDFile= му кажува на менаџерот на услуги од каде да го чита идентификаторот на главниот процес. Менаџерот не ја пишува таа датотека, но ја отстранува преостанатата по исклучувањето, и токму затоа прекинат излез може да остави датотека.

Оваа поделба на одговорност објаснува два симптома што луѓето ги пријавуваат како грешки. Датотека што никогаш не се појавува значи дека демонот или неговата скрипта не успеале да ја напишат, а не дека надзорот е погрешно конфигуриран. Датотека што преживува запирање значи дека патеката на исклучување никогаш не завршила.

Тоа исто така објаснува зошто тековните упатства предлагаат да се избегнува конвенцијата кога надзорот може директно да го следи главниот процес. Тие упатства не се дозвола да се менува типот на спакувана единица, бидејќи однесувањето на демонот во преден план, при разгранување или при известување мора да одговара на она што единицата го декларира. Сменете го типот без да го смените демонот и ќе добиете единица што пријавува неуспех додека тунелот работи, или обратно. Усогласете го парот или оставете ги двете. Референцата за услугата systemd ја опишува поделбата на сопственост.

Чисто исклучување наспроти прекинат излез

Чистото запирање бара од демонот да излезе, го чека и му дозволува на менаџерот да го среди сопственото книговодство. Прекинат излез, убиен процес или рестартирање среде исклучување прескокнуваат делови од таа низа, и датотеката е она што останува. Наоѓањето на една по пад ви кажува дека исклучувањето не завршило, а не дека нешто слуша.

Споредете ја временската ознака на датотеката со последното подигнување и со последното запирање на единицата.

Потоа проверете ги живите докази директно. Сокет врзан за портата на VPN и мрежен интерфејс на тунел со адреса се доказ дека нешто работи, на начин на кој текстуална датотека во директориум за извршување никогаш не е. Ако и двете недостасуваат, ништо не работи, што и да тврди датотеката.

Престанете да ја бришете датотеката од навика

Нејзиното бришење е легитимен чекор за обновување откако ќе утврдите дека ниту една инстанца не ја поседува и дека стартерот го документира ова однесување.

Како постојана навика пред стартување, тоа ја поништува проверката што ја заобиколувате. Ако застарените датотеки се враќаат по секое чисто запирање, писателот и животниот циклус на исклучување не се согласуваат за тоа кој ја поседува патеката, и тоа несогласување е грешката што вреди да се поправи.

Одржувајте независен начин за влез во домаќинот, стартувајте една инстанца преку нејзиниот нормален менаџер и прочитајте го првиот резултат. Следниот човек добива единица што или работи или се објаснува.

Поврзани статии