armbian-truncate-logs and PostgreSQL

[Tim Makarios]

One of my Armbian machines (24.5.5 bookworm) is running PostgreSQL.  I don't think I've changed any of its default settings relating to PostgreSQL's log files or their permissions, but I'm occasionally getting emails from the armbian-truncate-logs cron job saying:

Quote

truncate: cannot open '/var/log/postgresql/postgresql-15-main.log' for writing: Permission denied

The directory /var/log/postgresql is owned by root (and group postgres) and has permissions drwxrwxr-t, and the file /var/log/postgresql/postgresql-15-main.log is owned by postgres (and group adm) and has permissions -rw-r-----.

 

In /var/log.hdd/postgresql the ownership and permissions are the same, and there are also files postgresql-15-main.log.1, postgresql-15-main.log.2.gz, postgresql-15-main.log.3.gz, ..., postgresql-15-main.log.10.gz (with the same ownership and permissions as postgresql-15-main.log).  The file postgresql-15-main.log.1 is a prefix of postgresql-15-main.log.

 

I have this problem only with PostgreSQL's logs; armbian-truncate-logs doesn't complain about any other log files.

 

Is there something I need to do to fix this, or is this a bug that will be fixed in future?

[Tim Makarios]

I seem to have successfully worked around this problem by changing the permissions on /var/log/postgresql.  I'm not sure why the cron job, which looks like it's set up to run as root, couldn't truncate the file in that folder; and I'm not sure whether my solution is durable, or whether a reboot or something might reset the permissions at some stage, but it works for now.

[Tim Makarios]

It does, indeed, seem to have reverted to the problematic permissions after a reboot.

[Wytze van der Raay]

As far as I know, the permissions of /var/log/postgresql after a reboot are recreated from those on /var/log.hdd/postgresql. So if you modify those as well (remove the sticky bit), the workaround should be permanent.

 

Thanks for highlighting this problem, I've encountered the very same issue, but didn't realize it was caused by this somewhat peculiar directory permission. So I just applied your workaround (plus my extension) and hope it will fix this once and for all.