1

summary: I want to keep an OpenVPN client's main log from filling its filesystem, but I also need to keep a fairly high debug level (at least for now). My attempt to logrotate is currently not behaving as intended (though it's probably behaving as directed :-(

details:

I'm definitely underskilled as a Linux administrator, so feel free to correct any errors or misperceptions embedded below. I've got a laptop with

$ cat /etc/debian_version
jessie/sid
$ uname -rv
3.11-2-amd64 #1 SMP Debian 3.11.8-1 (2013-11-13)
$ sudo openvpn --version | head -1
OpenVPN 2.3.2 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [IPv6] built on Nov 28 2013
$ sudo logrotate --version | head -1
logrotate 3.8.6

on which I'm setting up an OpenVPN client for the first time. The client is not yet working, so ISTM I need to keep my OpenVPN log @ /var/log/openvpn.log fairly informative. Unfortunately I started getting notification=Low Disk Space on "Filesystem root", since I have /var on my LVM2 root volume. After manually deleting /var/log/openvpn.log a few times, I decided, "time to learn to use logrotate". After reading a bit, I created /etc/cron.hourly/logrotate with

#!/bin/sh

test -x /usr/sbin/logrotate || exit 0
/usr/sbin/logrotate /etc/logrotate.conf

and appended the stanza for /var/log/openvpn.log below to my /etc/logrotate.conf (i.e., everything before # for OpenVPN client was in the /etc/logrotate.conf installed by debian):

# see "man logrotate" for details
# rotate log files weekly
weekly

# keep 4 weeks worth of backlogs
rotate 4

# create new (empty) log files after rotating old ones
create

# uncomment this if you want your log files compressed
#compress

# packages drop log rotation information into this directory
include /etc/logrotate.d

# no packages own wtmp, or btmp -- we'll rotate them here
/var/log/wtmp {
    missingok
    monthly
    create 0664 root utmp
    rotate 1
}

/var/log/btmp {
    missingok
    monthly
    create 0660 root utmp
    rotate 1
}

# system-specific logs may be configured here

# for OpenVPN client
/var/log/openvpn.log {
    missingok
    copytruncate
    size 100M
    rotate 5
    dateformat -%Y%m%d_%H%M
    dateext
    compress
    delaycompress
    nomail
}

I.e., my intention was that,

  1. cron would run logrotate hourly.
  2. Once /var/log/openvpn.log got bigger than 100 MB, logrotate would copytruncate it (to allow process=openvpn to continue to write the original logfile).
  3. Each copytruncated log section would be timestamped with format=%Y%m%d_%H%M (which works at commandline with date +%Y%m%d_%H%M)
  4. Each copytruncated log section would be compressed; I'm using delaycompress since it seems safer than not using it :-)
  5. I would keep up to 5 log sections, and thus not more than 500 MB of OpenVPN log. (And hopefully less, since I'm compressing.)

Unfortunately, I'm still getting the root-full notifications, with situations like

$ df -h
Filesystem                   Size  Used Avail Use% Mounted on
/dev/mapper/LVM2_crypt-root   20G   20G     0 100% /
udev                          10M     0   10M   0% /dev
tmpfs                        390M  1.1M  389M   1% /run
tmpfs                        5.0M     0  5.0M   0% /run/lock
tmpfs                        1.6G  876K  1.6G   1% /run/shm
/dev/sda3                    485M   33M  423M   8% /boot
/dev/mapper/LVM2_crypt-home  322G  228G   95G  71% /home
none                         4.0K     0  4.0K   0% /sys/fs/cgroup

$ sudo rm /var/log/openvpn.log
rm: cannot remove ‘/var/log/openvpn.log’: No such file or directory

$ ls -alS /var/log/ | head
total 5521688
-rw-------  1 root root 5636743168 Mar  6 14:21 openvpn.log-20150306_%H%M
...

$ sudo rm /var/log/openvpn.log*

$ df -h
Filesystem                   Size  Used Avail Use% Mounted on
/dev/mapper/LVM2_crypt-root   20G   15G  4.3G  78% /
...

So I have 3 questions, in ascending order of importance (to me):

  1. Why is logrotate timestamping incorrectly? I.e., why is it creating openvpn.log-20150306_%H%M instead of openvpn.log-20150306_1421 ?
  2. Why is logrotate creating a 5-GB logfile segment, instead of rotating @ 100 MB as directed?
  3. How best to fix this problem?
  • copytruncate is not so great. OpenVPN recommends using syslog for logging and does not support log rotate in itself. You could feed logs to syslog, configure syslog to log to a specific file the openvpn stuff and setup log rotation of those files. – ysdx Mar 9 '15 at 12:22
1

This is a very broad question. I'll try to address a few of these.

As installed, logrotate is called daily via a cron type of situation. In Centos 7, you can find the invokation of logrotate under /etc/cron.daily which is invoked via the daily entry (0daily) in a /etc/cron.d file. Of course, you can make changes to run this every hour or make further calls to logrotate from special entries in the root crontab.

If you look at the man page, you will find that the dateformat has restrictions "Only %Y %m %d and %s specifiers are allowed.". Thus your specification issue.

It looks like your resulting rotated file is VERY large and seems to be a full day log. This is most likely due to the specification error since the data is being copied into the same file. And since the compression will only occur on cycles later than the currently rotated one it is probable that you'll have basically two huge files. As no new logrotate files would be created for a 24 hour period, the compression did not happen as you expected.

Final note is that some enlightened packages now include the scripting for logrotate that will do this by default. These entries are usually placed in files under /etc/logrotate.d instead of the using the single logrotate.conf file. These files are then included when logrotate runs by default with an "include" directive in /etc/logrotate.conf. This include directive is present in nearly every stock logrotate installation I am aware of these days.

  • If you read through OP's admittedly somewhat long question, OP installed an hourly cronjob for logrotate. I suspect the only problem OP is running in to is the disallowed use of %H and %M – derobert Mar 8 '15 at 3:49
  • Edited based on your feedback. – mdpc Mar 8 '15 at 5:59
  • So cron.hourly should actually run hourly if I fix the dateformat? – TomRoche Mar 9 '15 at 4:18
  • The rotation should happen hourly and as you expect if the resulting destination filenames do not conflict. – mdpc Mar 9 '15 at 4:45

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.