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 неважны для того, куда ушли сообщения.

Повышайте подробность только после того, как сможете её прочитать

Повышение подробности до того, как найдено место назначения, лишь создаёт больше текста там, куда вы не смотрите.

Когда вы знаете, куда попадает вывод, умеренный уровень показывает разбор профиля и попытку соединения. Двух или трёх достаточно при проблеме запуска. Более высокие уровни оправданы, когда сбой — деталь переговоров, и они же быстро увеличивают файл.

Затем прочитайте настоящую ошибку. Тихий терминал ничего не доказывает насчёт того, поднялся ли туннель, а сбой, записанный в файле, — именно тот, который стоит исправлять.