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

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

Упоредите два начина покретања уместо да закључите да је један од њих покварен. Прочитајте командну линију unit-а и његово окружење, затим прочитајте дневник за исти временски прозор. Ако омотач преусмерава излаз у сопствену датотеку, та датотека је сада ваш дневник, а OpenVPN директиве су неважне за то где су поруке отишле.

Повећајте детаљност само када можете да је прочитате

Повећање детаљности пре проналажења одредишта само ствара више текста на месту које не гледате.

Када знате где излаз слеће, умерен ниво показује да се профил парсира и да се веза покушава. Два или три су довољна за проблем при покретању. Виши нивои заслужују своје место када је отказ детаљ преговора, а и брзо увећавају датотеку.

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

Повезани чланци