Файл PID ёсць, тунэля няма: ці запускаўся OpenVPN?

Калі запускальнік адмаўляецца запусціць OpenVPN, бо файл PID ужо існуе, натуральнае чытанне — што дзесьці падняты тунэль. Гэтае чытанне даволі часта памылковае, каб яго варта было праверыць, перш чым нешта выдаляць. Файл у каталогу выканання — гэта ўлік, а ўлік перажывае збоі, перазагрузкі і перарваныя спыненні, якія не пакінулі пасля сябе працэсу. Справу вырашаюць два пытанні: ці ёсць жывы працэс і ці належыць гэты працэс дадзенаму асобніку.

Пачніце са службы, а не з файла

Адмова звычайна ідзе ад запускальніка, а не ад самога OpenVPN. Ён чытае шлях, знаходзіць там нешта і спыняецца, перш чым разбраць канфігурацыю. Такім чынам, першае пытанне — пра кантракт запускальніка, а не пра тунэль.

Прачытайце юніт або скрыпт, які выдаў паведамленне, і адзначце тры рэчы: шлях, які ён правярае, тып службы, які ён абвяшчае, і ці адказны ён наогул за запіс файла. Сучасны юніт можа выкарыстоўваць просты нагляд або нагляд апавяшчэнняў і зусім не чапаць файл PID, а стары init-скрыпт можа стварыць яго сам. Капіраванне праверкі з адной мадэлі ў другую дае менавіта такую адмову. Высветліце, якая мадэль выкарыстоўваецца, перш чым нешта тлумачыць.

Толькі тады пытанне робіцца пра тое, ці сапраўды працуе асобнік.

Праверце, ці належыць гэты ідэнтыфікатар вашаму асобніку

Лік у файле даказвае, што лік быў запісаны. Ён не даказвае, што працэс з гэтым ідэнтыфікатарам існуе зараз, і ўжо дакладна не даказвае, што працэс ваш, бо ідэнтыфікатары паўторна выкарыстоўваюцца пасля перазагрузкі.

Параўнайце час запуску працэсу з адзнакай часу файла, выканальны файл з камандай юніта, а членства ў службе з імем юніта. Няўзгодненасць у любым з трох азначае, што вы глядзіце на ўлік, а не на тунэль.

На хасце, які запускае кантэйнеры або некалькі прастораў імёнаў, ідэнтыфікатар можа мець сэнс у адным прадстаўленні і быць адсутным у іншым. Няздольнасць убачыць працэс таксама не доказ таго, што яго няма, калі ваш уліковы запіс не можа яго прагледзець. Правярайце з таго кантэксту, які выкарыстоўвае запускальнік, перш чым рабіць высновы.

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

Што запускальнік абяцаў зрабіць з файлам

PIDFile= паведамляе кіраўніку службаў, адкуль чытаць ідэнтыфікатар галоўнага працэсу. Кіраўнік не піша гэты файл, але ён выдаляе той, што застаўся пасля спынення, і менавіта таму перарваны выхад можа пакінуць файл.

Гэты падзел адказнасці тлумачыць два сімптомы, якія людзі паведамляюць як памылкі. Файл, які ніколі не з'яўляецца, азначае, што дэман або яго скрыпт не здолеў яго запісаць, а не што нагляд наладжаны няправільна. Файл, які перажывае спыненне, азначае, што шлях спынення ніколі не завяршыўся.

Гэта таксама тлумачыць, чаму сучасныя рэкамендацыі прапануюць пазбягаць гэтай умовы, калі нагляд можа адсочваць галоўны працэс напрамую. Гэтыя рэкамендацыі не дазвол мяняць тып спакаванага юніта, бо паводзіны дэмана ў пярэднім плане, пры разгалінаванні або пры апавяшчэнні павінны адпавядаць таму, што абвяшчае юніт. Змяніце тып, не змяняючы дэман, і вы атрымаеце юніт, які паведамляе пра збой, пакуль тунэль працуе, або наадварот. Узгадніце пару або пакіньце абодва. Даведнік па службе systemd апісвае падзел уласнасці.

Чыстае спыненне супраць перарванага выхаду

Чыстае спыненне просіць дэман выйсці, чакае яго і дазваляе кіраўніку прыбраць свой улік. Перарваны выхад, забіты працэс або перазагрузка падчас спынення прапускаюць часткі гэтай паслядоўнасці, і файл — гэта тое, што застаецца. Знайсці яго пасля збою азначае, што спыненне не завяршылася, а не што нешта слухае.

Параўнайце адзнаку часу файла з апошняй загрузкай і з апошнім спыненнем юніта.

Затым праверце жывыя доказы напрамую. Сокет, прывязаны да порта VPN, і інтэрфейс тунэля з адрасам — доказ таго, што нешта працуе, такім чынам, якім тэкставы файл у каталогу выканання ніколі не быў. Калі абодвух няма, нічога не працуе, што б ні сцвярджаў файл.

Перастаньце выдаляць файл па звычцы

Выдаленне — законны крок аднаўлення, калі вы ўстанавілі, што ні адзін асобнік ім не валодае і што запускальнік дакументуе гэтыя паводзіны.

Як пастаянная звычка перад запускам, яно знішчае праверку, якую вы абыходзіце. Калі састарэлыя файлы вяртаюцца пасля кожнага чыстага спынення, той, хто піша, і жыццёвы цыкл спынення не згаджаюцца, каму належыць шлях, і гэта нязгода — памылка, якую варта выправіць.

Трымайце незалежны шлях у хост, запусціце адзін асобнік праз яго звычайны кіраўнік і прачытайце першы вынік. Наступны чалавек атрымае юніт, які або працуе, або тлумачыць сябе.