OpenVPN Started but Printed Nothing: Check log-append First

You start OpenVPN from a shell with a configuration file, and the terminal sits there with no output at all. No banner, no error, no prompt. The instinct is that the launch failed, so you start another copy, then another, and the machine ends up with several half-configured instances. Before any of that, check the profile for a directive that already redirected the log somewhere else. Silence is a property of the console, not of the process.

Silence has two very different explanations

The first is that the process is running fine and writing to a file you are not watching. The second is that it exited immediately with an error recorded in that same file.

Both leave an empty terminal, and one question separates them: is there a process now, and what is in the file it was told to write. Answer that before touching the configuration again. Relaunching to get output is how two instances end up fighting over one tunnel device and the same port, which produces errors that have nothing to do with the original problem.

Find the directive, then find the process.

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

Find the destination the running process uses

Read the profile the process was actually started with, not the one you edited. A service-managed instance usually loads a different path and runs with a different working directory, so a relative filename resolves somewhere you did not expect.

An explicit cd directive makes that distinction sharper, because the relative path moves with the directory change. If you inherited this configuration, the file may sit in a place nobody would look for it now.

Check the file's modification time against the moment you launched. A log from last week is evidence about last week. Then read the last lines of the file that changed, and treat whatever is there as the startup message you have been missing.

log versus log-append: evidence and erasure

log-append adds to whatever is already in the file. log opens the file for writing and truncates it, so switching between the two can delete the run you were about to read.

If someone changed the directive while debugging, the previous evidence is already gone and the file's size will look suspiciously small. That is worth knowing before you compare two runs and conclude something changed. Delete a log on purpose, or keep it, but know which you did. Evidence you removed deliberately is easier to reason about than evidence you lost by accident.

Neither option creates missing parent directories, and neither grants access through filesystem permissions or a service sandbox. A path that looks correct in the configuration can still be unwritable by the account the daemon runs as, in which case the daemon may fail before it can report anything. Check the directory's existence and its owner before assuming the filename is the problem.

When a service wrapper captures the output

Under systemd, standard output and error go to the journal unless an explicit file directive takes precedence, and a vendor wrapper may capture them somewhere else entirely.

That is why the same profile behaves differently from a shell and from a unit. The unit's environment, its working directory and its standard streams all differ from your interactive shell. A relative path can resolve in one context and land nowhere in the other. Read the unit definition when the two disagree, not the profile.

Compare the two launch arrangements instead of concluding that one of them is broken. Read the unit's command line and its environment, then read the journal for the same time window. If the wrapper redirects output to its own file, that file is your log now, and the OpenVPN directives are irrelevant to where the messages went.

Turn verbosity up only after you can read it

Increasing verbosity before finding the destination just produces more text in a place you are not looking.

Once you know where the output lands, a moderate level shows the profile being parsed and the connection being attempted. Two or three is enough for a startup problem. Higher levels earn their place when the failure is a negotiation detail, and they also make the file grow quickly.

Then read the actual error. A silent terminal proves nothing about whether the tunnel came up, and the failure recorded in the file is the one worth fixing.