4

I moved logging for openvpn into its own log and attempted to set up log rotation for it, but I've obviously done something wrong.

Logging occurs as desired but always into the 2nd logfileopenvpn.log.1. The 'current' logfile openvpn.log exists, but is always empty.

-rw------- 1 root root     0 Apr 20 07:35 openvpn.log
-rw------- 1 root root  5411 Apr 20 07:58 openvpn.log.1

Here's my logrotate configuration file for openvpn.

/var/log/openvpn.log {
       daily
       rotate 7
       delaycompress
       compress
       notifempty
       missingok
}

The line in Openvpn's server.conf regarding logging is

log-append /var/log/openvpn.log

What did I mess up?

1
  • Came across this page while looking for a solution to log rotation. Thanks for the info, but I think I found a better solution on the OpenVPN support pages: openvpn.net/vpn-server-resources/… They give step by step instructions for configuring log rotation, you may find it better than what is given here. – Gordon Brandt Jan 18 at 15:10
1

You should make your service aware of log rotation. Some services may be killed with HUP signal some may need a full restart. It is possible that service opens the openvpn.log file, which is renamed to openvpn.log.1.

Try to add:

postrotate
    systemctl restart openvpn.service
endscript

I don't know exactly how your service is called, so my guess for openvpn.service may be wrong.

5
  • What do I add that to? – Organic Marble Apr 20 '18 at 14:06
  • To logrotate configuration for openvpn. After missingok line would be just fine. – nobody Apr 20 '18 at 14:07
  • Ok, will try. Won't be able to confirm if it works until tomorrow. Upvoted. – Organic Marble Apr 20 '18 at 14:09
  • This answer works, after a service restart it writes into the openvpn.log file. So I'm accepting it. But, I don't really want to restart the service every day, in case I happen to be using it then. I will keep researching. – Organic Marble Apr 24 '18 at 1:51
  • You have to tell service that log file has changed. Some services like apache accept HUP signal. For some you can use reload. Some you have to restart. Find out what can you do with your service. – nobody Apr 24 '18 at 8:17
8

According to this old post on the openvpn-users mailing list :

openvpn logging is done by redirecting stdout/stderr to the logfile

So the solution is to use the copytruncate option in the logrotate configuration:

copytruncate

Truncate the original log file to zero size in place after creating a copy, instead of moving the old log file and optionally creating a new one. It can be used when some program cannot be told to close its logfile and thus might continue writing (appending) to the previous log file forever. Note that there is a very small time slice between copying the file and truncating it, so some logging data might be lost. When this option is used, the create option will have no effect, as the old log file stays in place.

This is what I have in my /etc/logrotate.d/openvpn file :

/var/log/openvpn.log {
    weekly
    rotate 12
    copytruncate
    compress
    delaycompress
    missingok
    notifempty
}

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.