Има PID файл, няма тунел: стартирал ли е изобщо OpenVPN?

Когато стартерът откаже да стартира OpenVPN, защото вече съществува PID файл, естественото четене е, че някъде работи тунел. Това четене е достатъчно често погрешно, за да си струва проверка, преди да се изтрие нещо. Файл в директория за изпълнение е отчетност, а отчетността преживява сривове, рестарти и прекъснати спирания, които не са оставили процес. Два въпроса решават случая: има ли жив процес и принадлежи ли този процес на тази инстанция.

Започнете с услугата, не с файла

Отказът обикновено идва от стартер, а не от самия OpenVPN. Той чете път, намира нещо там и спира, преди да разчете конфигурация. Следователно първият въпрос е за договора на стартера, а не за тунела.

Прочетете unit-а или скрипта, който отпечата съобщението, и отбележете три неща: пътя, който проверява, типа услуга, който декларира, и дали изобщо отговаря за записването на файла. Модерен unit може да използва проста или notify-наблюдение и никога да не пипа PID файл, докато по-стар init скрипт може сам да създаде такъв. Копирането на проверка от един модел в друг произвежда точно такъв отказ. Разберете кой модел се използва, преди да тълкувате каквото и да е.

Едва тогава въпросът става дали дадена инстанция действително работи.

Проверете дали този идентификатор принадлежи на вашата инстанция

Число във файл доказва, че е било записано число. То не доказва, че процес с този идентификатор съществува сега, и със сигурност не доказва, че процесът е ваш, защото идентификаторите се използват повторно след рестарт.

Сравнете часа на стартиране на процеса с времевата марка на файла, изпълнимия файл с командата на unit-а, а членството в услугата с името на unit-а. Несъответствие в което и да е от трите означава, че гледате отчетност, а не тунел.

На хост с контейнери или няколко пространства от имена идентификаторът може да има смисъл в един изглед и да липсва в друг. Да не виждате процес също не е доказателство, че той не съществува, ако акаунтът ви не може да го инспектира. Проверявайте от контекста, който използва стартерът, преди да правите изводи.

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

Какво е обещал стартерът да направи с файла

PIDFile= казва на мениджъра на услуги откъде да чете идентификатора на главния процес. Мениджърът не пише този файл, но премахва оцелял след спиране, и точно затова прекъснато излизане може да остави файл.

Това разделение на отговорности обяснява два симптома, които хората докладват като грешки. Файл, който никога не се появява, означава, че демонът или скриптът му не са го записали, а не че наблюдението е конфигурирано грешно. Файл, който оцелява след спиране, означава, че пътят на спиране никога не е завършил.

Това също обяснява защо актуалните насоки препоръчват да се избягва конвенцията, когато наблюдението може да следи главния процес директно. Тези насоки не са разрешение да се променя типът на пакетиран unit, защото поведението на демона на преден план, при разклоняване или при уведомяване трябва да съответства на това, което unit-ът декларира. Променете типа, без да променяте демона, и ще получите unit, който докладва неуспех, докато тунелът работи, или обратното. Съпоставете двойката или оставете и двете. Справочникът за услугата systemd описва разделението на собствеността.

Чисто спиране срещу прекъснато излизане

Чистото спиране иска от демона да излезе, изчаква го и позволява на мениджъра да подреди собствената си отчетност. Прекъснато излизане, убит процес или рестарт по време на спиране пропускат части от тази последователност и файлът е това, което остава. Намирането му след срив ви казва, че спирането не е завършило, а не че нещо слуша.

Сравнете времевата марка на файла с последното зареждане и с последното спиране на unit-а.

След това проверете живите доказателства директно. Сокет, свързан с порта на VPN, и интерфейс на тунел с адрес са доказателство, че нещо работи, по начин, по който текстов файл в директория за изпълнение никога не е. Ако и двете липсват, нищо не работи, каквото и да твърди файлът.

Спрете да триете файла по навик

Изтриването е законна стъпка за възстановяване, след като установите, че никоя инстанция не го притежава и че стартерът документира това поведение.

Като постоянен навик преди стартиране то обезсмисля проверката, която заобикаляте. Ако стари файлове се връщат след всяко чисто спиране, записващият и жизненият цикъл на спиране не са съгласни кой притежава пътя, и това несъгласие е грешката, която си струва да се поправи.

Пазете независим път до хоста, стартирайте една инстанция през нормалния и мениджър и прочетете първия резултат. Следващият човек получава unit, който или работи, или се обяснява.