Reputation: 3008
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?
Upvotes: 54
Views: 70875
Reputation: 2080
How do all these answers address the issue reported by logrotate
itself?
It says: "... because parent directory has insecure permissions (It's world writable or writable by group which is not "root")."
I can't see why using su user group
fixes the parent folder permissions. And it didn't on my production system (I'm admin of the latter).
This is how I fixed it, just 1 hour ago: making happy logrotate, the webapp, and continuous deployment. Note that this may not be needed if you only want to rotate apache2 logs, but if your logs are in a specific log folder, it will help.
Let's say, for this use case, that your log folder, for CD permission strategy reasons, must be owned by gitlab-runner
, and that you need to preserve Apache's ability to create app log files within the same folder:
So this is the trick: make your webserver process be able to create new app log files, yet make that folder "rotatable":
Well this is the only fix I found to make all these processes happy. Using su itself in logrotate config file did not do, since the parent folder group was still not root. Which I found was a ridiculous requirement.
Again, this use case is a more specific one, where the Apache logs are located in the same log folder as the app logs, in an attempt to centralise them all. I thought it could help that I outlined the folder group requirement: "root".
Upvotes: 1
Reputation: 311
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
Upvotes: 2
Reputation: 3008
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>
Upvotes: 59
Reputation: 2619
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.
Upvotes: 5
Reputation: 1523
just add su root adm
to the config file:
/var/log/apache2/*.log {
# …
su root adm
}
Upvotes: 76