OpenVPN стартира, но не отпечата нищо: първо проверете log-append

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

Тишината има две много различни обяснения

Първото е, че процесът работи добре и пише във файл, който не наблюдавате. Второто е, че е излязъл веднага с грешка, записана в същия файл.

И двете оставят празен терминал и един въпрос ги разделя: има ли сега процес и какво има във файла, в който му е наредено да пише. Отговорете на това, преди отново да пипате конфигурацията. Рестартирането за получаване на изход е начинът, по който две инстанции се сблъскват за едно тунелно устройство и един и същ порт, което създава грешки без връзка с първоначалния проблем.

Намерете директивата, после намерете процеса.

ps -o pid,args= -C openvpn
grep -nE '^\s*(log|log-append|cd|daemon|verb)\b' /etc/openvpn/server/server.conf

Намерете дестинацията, която използва работещият процес

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

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

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

log срещу log-append: доказателство и изтриване

log-append добавя към това, което вече е във файла. log отваря файла за писане и го отрязва, така че превключването между двете може да изтрие пускането, което сте щели да четете.

Ако някой е променил директивата по време на отстраняване на грешки, предишното доказателство вече е изчезнало и размерът на файла ще изглежда подозрително малък. Това си струва да се знае, преди да сравнявате две пускания и да заключите, че нещо се е променило. Изтрийте журнал нарочно или го запазете, но знайте кое сте направили. Доказателството, което сте премахнали умишлено, е по-лесно за осмисляне от доказателството, което сте загубили случайно.

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

Когато служебна обвивка прихване изхода

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

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

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

Увеличете подробността само след като можете да я четете

Повишаването на подробността преди намиране на дестинацията просто създава повече текст на място, където не гледате.

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

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