Who Owns OpenVPN Logs: the Daemon, rsyslog or logrotate?

Log rotation breaks in a predictable way: three components each believe they own the file, and the result is a rotated log that keeps growing while the new one stays empty. The daemon holds a descriptor, logrotate renames the path, and rsyslog writes somewhere else entirely. Pick one writer and one rotator before adding another rule to the pile. The checklist below moves in that order because every later step depends on it.

Decide who writes the file

Two designs are legitimate. In the first, the VPN process writes a file itself through its own log or log-append option. In the second, it sends records to the system logger and rsyslog or journald decides where they land.

They are alternatives, not layers. A host that enables both ends up with two files that disagree, and the one you are reading is often the stale one. Pick the path deliberately, then remove the other writer.

Read the effective service configuration before you change anything, including drop-ins that may override the unit file. A directive present in the profile you edited is not proof that it is the one the running process loaded. Compare the unit with the process arguments, then with the files it actually opened.

Name the daemon so the filter can be narrow

On the syslog path, give the daemon a distinct identity and filter on it. A rule that matches the program name of this VPN instance keeps its records out of a shared file whose retention policy belongs to something else.

Narrow rules also make the next question answerable: which service produced this line? A filter that matches everything with the word VPN in it will happily collect a second tunnel's traffic and blur both. Match on the exact identifier the unit passes to the logger.

Close the rule after the action so the records do not also fall through to the default destination. Duplicate lines in two files look like a logging bug and are really a missing stop. That single omission also doubles the disk cost of the retention policy.

Rotate without losing the descriptor

When the daemon writes the file, logrotate renames the path but the process keeps its open descriptor. New records continue into the renamed file until something makes the process reopen the original path, which is why a rotation can appear to work while the new file stays empty.

The fix is a postrotate action that triggers the service's documented reload or restart behaviour. Signalling the logger is a different action entirely and does nothing for a daemon holding its own file.

Where a reopen is impossible, copytruncate is the fallback: copy the file, then truncate it in place. It keeps the descriptor valid at the cost of losing anything written between the copy and the truncation, so it is a trade rather than a solution. Under load that gap can swallow the very failure you are trying to capture.

Choose one of the two per file and write the choice down, because mixing them on the same path produces gaps that are very hard to attribute later. A reader who finds both patterns in one directory cannot tell which one is authoritative.

Set retention from the incident window

Retention, compression and maximum size should follow from how far back you actually investigate. A seven-day window with compression and a size cap is a reasonable starting point for many deployments, and a number copied from a tutorial is not.

Keep the policy in one place. If logrotate rotates the file and rsyslog also rotates it, the second rotation wins and the first one's naming scheme survives as clutter. Pick the owner, disable the other rotation, and note that decision beside the policy.

The rsyslog documentation covers its routing and action model, while the OpenVPN service documentation stays authoritative for the daemon's own logging options. Neither one decides your retention policy for you.

Test one rotation and one fresh event

Force a single rotation and then generate one new event, such as a failed authentication. Confirm the new record appears in the new file and that the old file stopped growing.

Check permissions on the new file as well, because a rotation that recreates it with a different owner breaks the writer on the next write and produces a gap that looks like a crash. Compare the owner and mode against the service account before you walk away. Then confirm the compressed archive is readable, since an archive nobody can open is not retention. A quick read of the newest record in the old file proves both the compression and the permissions.

Finish by recording the owner of each step: which component writes, which rotates, and where the retention policy lives. That record is what turns the next logging incident into a five-minute check instead of an afternoon of guessing which layer dropped the line.