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

Прачытайце код стану перад праграмай

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

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

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

Спытайце unit, дзе ён хоча быць

Чытайце эфектыўны unit, а не файл, які вы лічыце ўсталяваным, бо drop-in файлы могуць перазапісаць працоўны каталог, так і не змяніўшы галоўны unit. Вывад show адказвае на пытанне напрамкі:

systemctl cat [email protected]
systemctl show [email protected] -p WorkingDirectory -p RootDirectory -p User -p ProtectHome
journalctl -u [email protected] -b --no-pager | tail -30

Для шаблона сервера upstream працоўны каталог — гэта каталог канфігурацыі сервера, і назва асобніка выбірае профіль унутры яго. Таму асобнік з назвай branch чакае свой файл у тым жа каталозе, а профіль, змешчаны ў іншым месцы, зусім не задавальняе патрабаванне працоўнага каталога.

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

Праверце шлях так, як яго бачыць сэрвіс

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

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

namei -l /etc/openvpn/server
systemctl show [email protected] -p ProtectSystem -p ReadOnlyPaths

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

Выпраўце ўладальніка, потым чакайце іншую памылку

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

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

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

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

Падобныя артыкулы