Where an OpenVPN server should write its log, and why

A log design is three answers: which process produced a record, where that record lands, and how long it survives. OpenVPN can write to a file, hand messages to the system logger, or leave them to whatever the service manager captures, and those are not three copies of one stream. Each choice changes who owns rotation, which user can read the result, and what happens during startup. Settle the answers before an incident, because afterwards you inherit whatever was configured.

What the daemon actually does with the directive

The directives are not abstractions; each one decides where the process writes its messages. log /path opens that file, log-append /path opens it for appending, and syslog hands messages to the local system logger over its socket. With none of them, output goes to standard output, which leaves the service manager to decide what happens next. Read the effective unit and the profile together before concluding that the daemon ignores your configuration.

That last case is the common one on a packaged install, and it explains why two administrators disagree about where the log lives. One reads the unit journal, the other reads a file the daemon never wrote.

Check the running configuration rather than the file on disk. A drop-in unit override or an environment file can change the effective directive without touching the profile you are reading.

log truncates, log-append does not

log truncates an existing file when the directive takes effect, so a restart erases the evidence from before it. log-append keeps what is there and adds to it. Neither option rotates anything, and neither reopens the file later on its own, which is why rotation needs cooperation.

If rotation renames the file while the daemon keeps writing to the old descriptor, the new file stays empty and disk use keeps climbing in the renamed one. Signal the process to reopen, or rotate with a copy-truncate strategy and accept the copy window.

The directory, ownership and permissions are part of the design. The daemon may run as an unprivileged user after startup, and a directory created by root at install time may not be writable then. Prepare it through packaging or the deployment process instead of fixing permissions during an incident.

The service manager keeps a second copy

systemd captures standard output and standard error by default, so a unit without explicit redirection already has a log. Adding a file directive gives two streams with different retention, different readers and different timestamps.

That is not automatically wrong, but it has to be a decision. Keep the startup record in the journal, because failures before the configured file exists appear nowhere else. Then make the file authoritative for steady-state events and say so in the runbook. Two authoritative streams mean two answers to every question.

Confirm the choice with a test that fails on purpose. Start the daemon with an unreadable certificate and check which stream records the error.

Verbosity is not the same as detail you can use

A higher verb level adds more lines, and past a point it adds lines nobody reads. Level 3 is a reasonable steady state for most deployments, while level 4 and above suit a bounded investigation with a known question. Repetition suppression reduces noise, but it must not hide how often an event recurs. Set the level you can sustain, and raise it only for a named investigation with an end.

Keep instance identity and timestamps in the record. A reconnect looks exactly like a first connection when the file has been appended to for months and the instance name is missing.

Be careful what else lands in that file. Redirected output can include text from called scripts, and a helper that echoes its environment puts credentials and key paths into a readable log. Treat log access as a security decision even when the daemon itself prints nothing sensitive.

Rotation, retention and the signals that reload

Decide retention with the person who owns the disk, and set it before the volume decides for you. A reload signal is not a log-maintenance command: sending the wrong one restarts the tunnel and disconnects every user. Write the reopen procedure beside the rotation rule so the two cannot drift apart.

The result should be a service an operator can describe: one authoritative stream, each event placed in the lifecycle, and a record obtainable without collecting every secret-bearing file on the host. That description is the acceptance test for the design, and it is cheap to check before the next incident.