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, стандардниот излез и грешките одат во дневникот на системот, освен ако експлицитна директива за датотека има предност, а обвивката на производителот може да ги пресретне сосема на друго место.

Затоа истиот профил се однесува поинаку од школка и од systemd единица. Окружувањето на единицата, нејзината работна папка и стандардните текови се разликуваат од вашата интерактивна школка. Релативна патека може да се разреши во еден контекст, а во другиот да не води никаде. Кога двете не се согласуваат, читајте ја дефиницијата на единицата, а не профилот.

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

Зголемете ја деталноста само откако ќе можете да ја прочитате

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

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

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