Apache and logrotate configuration

Question

Last week I found a problem on my server, because the disk usage was 100%, and I found out apache had created a huge error.log file of 60GB. I changed then the LogLevel to emerg, but after one week, it is again 1.3GB which is definitely too much.

Moreover, I have an access.log of 6MB and an other_vhosts_access.log of 167MB. So I found out that the problem could be logrotate not working. Actually the gzipped files of the logs have a very old date (23rd February).

So I tried first to change the configuration of the logrotate file for apache2, adding a max size for the file, looking now like this:

/var/log/apache2/*.log {
    weekly
    size 500M
    missingok
    rotate 20
    compress
    delaycompress
    notifempty
    create 640 root adm
    sharedscripts
    postrotate
                if /etc/init.d/apache2 status > /dev/null ; then \
                    /etc/init.d/apache2 reload > /dev/null; \
                fi;
    endscript
    prerotate
        if [ -d /etc/logrotate.d/httpd-prerotate ]; then \
            run-parts /etc/logrotate.d/httpd-prerotate; \
        fi; \
    endscript
}

After this I tried manually to force logrotate to run a specific configuration for apache with

logrotate -f /etc/logrotate.d/apache2

and I got this error:

error: skipping "/var/log/apache2/access.log" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.
error: skipping "/var/log/apache2/error.log" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.
error: skipping "/var/log/apache2/other_vhosts_access.log" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.

The strange thing is that in some way it run the rotation, creating an empty error.log file, but with different permissions from the old one, and not compressing the existing error.log.

Looking at apache log directory, it looks now like this:

-rwxrwxrwx  1 root           adm            6.3M Oct 21 10:54 access.log
-rwxrwxrwx  1 root           adm             22K Feb 18  2014 access.log.1
-rwxrwxrwx  1 root           adm            7.0K Feb 16  2014 access.log.2.gz
-rwxrwxrwx  1 root           adm            4.0K Feb  9  2014 access.log.3.gz
-rw-------  1 amministratore amministratore    0 Oct 21 10:32 error.log
-rw-r--r--  1 root           root           1.3G Oct 21 10:57 error.log.1
-rwxrwxrwx  1 root           adm            167M Oct 21 10:57 other_vhosts_access.log
-rwxrwxrwx  1 root           adm            225K Feb 23  2014 other_vhosts_access.log.1
-rwxrwxrwx  1 root           adm             16K Feb 15  2014 other_vhosts_access.log.2.gz
-rwxrwxrwx  1 root           adm            3.2K Feb  8  2014 other_vhosts_access.log.3.gz

So what is the right way to proceed?

Should I change the permissions of the /var/log/apache2 directory? (which is now 777) I didn't set these permissions and I don't know if it is correct.

Or should I tell logrotate which user to use for rotation? And how?

Solution 1

Following the instructions from a Website, I have just changed the logrotate configuration file, adding the requested su directive as follows and now it rotates in the right way.

su <user> <group>

Solution 2

just add su root adm to the config file:

/var/log/apache2/*.log {
    # …
    su root adm
}

Solution 3

I've got "parent directory has insecure permissions" on attempt to force-rotate syslog.
Here is how I solved it:

cat /etc/logrotate.conf
    ...
    # use the syslog group by default, since this is the owning group
    # of /var/log/syslog.
    su root syslog

vim /etc/logrotate.d/rsyslog
    # Add to top:
    su root syslog

logrotate -f /etc/logrotate.d/rsyslog
    # No errors now, log is rotated.

Solution 4

You may add a "su " in the logrotate config file

OR

change the parent directory's permissions to 755. In your case:

 chmod 755 /var/log/apache2

View more solutions

Comments

[Randy Skretka]

Just gave you a +1. I was trouble shooting for an embarrassing length of time wondering why my anacron logrotate did not work. My log directory was own by me. logrotate needs owner to be root in this case. So I chown the log dir to root and added su root me to the logrotate config file. Thanks for posting your solution.

[Pete]

The username and group after su has to mach the log file(s). In my case I had to add: su syslog adm

[Agent47DarkSoul]

I don't understand why logrotate cares about this?

[augurar]

Can you summarize the instructions in case that link stops working?

[marengaz]

well, the link stopped working! i think when you specify su <user> <group> in the config file, logrotate runs as the specified user and group. ie. new files will be created with these permissions

[Phillipp]

The answer does not give any background WHY this is a problem and other ways to solve it (maybe the permissions are a problem!). Not cool.

[B. Shea]

Please try and avoid posting external links. Link now broken. Surprise, surprise..

[Gabor Garami]

Is there any other way to solve this problem? We have a webserver with dynamically expanding vhosts and I'd prefer to not have a logrotate config for every single site, but still want to rotate their logs. If logrotate could take the current permission, it'd be fine.

[piit79]

@Pete, that's not true. The user/group just needs sufficient privileges to rename/truncate the log files and to create new ones.

[scones]

this answer assumes the user and group and can only be valid for certain use cases on certain setups.

[pbies]

You need this solution in /etc/logrotate.d/apache2 file.

[Fabien Haddadi]

Nope. No cigar. I'm having the same bad time as the original author, despite I added su user group in /etc/logrotate.d/apache2config file. BTW, the test conducted by logrotate, is, IMHO, ridiculous and out of scope. It says it itself: "the parent folder ... or writable by group which is not "root", which means: whatever you stick as parent folder group, it MUST be root, or I'll refuse to do my job. Why does it matter if the folder group is not root, after all? Why would all these answers asking to use su fix the issue? they won't act on the parent folder group, will they?

[skomisa]

All you have done is repeat information provided in several other answers that were posted here years earlier, but without any detail or explanation. Before posting you are expected to check that you are not just repeating information in existing answers.