Logrotate not working due to file permission

[carsonip]

With umask 002, when I git clone the repo, the conf/etc/logrotate.d/graphite-statsd has file permission 664. But logrotate doesn't like that:

/ # logrotate -vdf /etc/logrotate.d/graphite-statsd 
WARNING: logrotate in debug mode does nothing except printing debug messages!  Consider using verbose mode (-v) instead if this is not what you want.

Potentially dangerous mode on /etc/logrotate.d/graphite-statsd: 0664
error: Ignoring /etc/logrotate.d/graphite-statsd because it is writable by group or others.
Reading state from file: /var/lib/logrotate.status
Allocating hash table for state file, size 64 entries

Handling 0 logs

This means if the project is cloned and run with docker-compose and default system settings, logrotate most probably won't work.

[carsonip]

If I change file permission to 644 before building the docker image, logrotate will work. Should we fix file permissions in Dockerfile?

[piotr1212]

With umask 002,

default system settings

On which OS a umask of 002 is default? That seems quite odd to me.

[carsonip]

With umask 002,

default system settings

On which OS a umask of 002 is default? That seems quite odd to me.

I'm using Linux Mint 19.1, which is based on Ubuntu 18.04. I have an EC2 instance on AWS with Ubuntu 16.04 and I also see 664 file permission. Not sure if it is normal.

[carsonip]

Just did some Googling, I suppose default umask is 002 for normal user, 022 for root user.

[deniszh]

I think it's better to fix that in runtime, because /etc/logrotate.d can be voulme. Will make a fix.

[deniszh]

Fixed in 1.1.5-13

[nikobearrr]

Hello, I experience the same issue.
I have a carbon.log file which is 1.5GB atm. When I try to manually log rotate I get this:

/etc # logrotate -vdf /etc/logrotate.d/graphite-statsd
WARNING: logrotate in debug mode does nothing except printing debug messages!  Consider using verbose mode (-v) instead if this is not what you want.

error: Ignoring /etc/logrotate.d/graphite-statsd because the file owner is wrong (should be root or user with uid 0).
Reading state from file: /var/lib/logrotate.status
Allocating hash table for state file, size 64 entries
Creating new state

Handling 0 logs

When I checked the /etc/logrotate.d it had owner 644:root

/etc/logrotate.d # ls -l
total 16
-rw-r--r--    1 644      root           140 Jun 12  2019 acpid
-rw-r--r--    1 644      root           135 Sep  5  2018 graphite-statsd
-rw-r--r--    1 644      root           122 Aug 14  2019 nginx
-rw-r--r--    1 644      root            52 May 21  2019 redis

When I changed it manually:

/etc/logrotate.d # chown root:root graphite-statsd

Then the logrotate worked fine.

In my carbon.conf I have set ENABLE_LOGROTATION = True, but it does not actually work.

I am running the graphite-statsd in a container and my Dockerfile looks like so:

FROM graphiteapp/graphite-statsd:1.1.7-1

ADD storage-schemas.conf /opt/graphite/conf/
ADD carbon.conf /opt/graphite/conf/
ADD udp.js /opt/statsd/config/

Do I need to manually chmod the logrotate config?

---

Edit:
I can see this is made on purpose: https://github.com/graphite-project/docker-graphite-statsd/blob/master/conf/entrypoint#L48
But the logrotation wouldn't work. Are there any workarounds?

[deniszh]

Argh.
That's a typo - https://github.com/graphite-project/docker-graphite-statsd/blob/master/conf/entrypoint#L48 should be chmod instead of chown.
Will fix it and make new release.

[deniszh]

Should be fixed in 1.1.7-2

[nikobearrr]

Thank you for the fast turnover @deniszh