# see "man logrotate" for details
# global options do not affect preceding include directives
# rotate log files weekly
weekly
# use the adm group by default, since this is the owning group
# of /var/log/.
su root adm
# keep 4 weeks worth of backlogs
rotate 4
# create new (empty) log files after rotating old ones
create
# use date as a suffix of the rotated file
#dateext
# uncomment this if you want your log files compressed
#compress
# packages drop log rotation information into this directory
include /etc/logrotate.d
# system-specific logs may also be configured here.
this is content of the directory:
leonbrag@beachpi:/etc/pihole$ ls -l /etc/logrotate.d/
total 64
-rw-r--r-- 1 root root 137 Nov 2 2023 alternatives
-rw-r--r-- 1 root root 151 Nov 2 2023 apport
-rw-r--r-- 1 root root 173 Apr 8 2022 apt
-rw-r--r-- 1 root root 112 Oct 30 2023 bootlog
-rw-r--r-- 1 root root 151 Nov 2 2023 btmp
-rw-r--r-- 1 root root 144 Mar 27 2024 cloud-init
-rw-r--r-- 1 root root 129 Nov 2 2023 dpkg
-rw-r--r-- 1 root root 440 Nov 6 2023 lighttpd
-rw-r--r-- 1 root root 97 Aug 23 2024 log2ram
-rw-r--r-- 1 root root 112 Nov 2 2023 ppp
-rw-r--r-- 1 root root 248 Mar 21 2024 rsyslog
-rw-r--r-- 1 root root 391 Oct 27 2023 rsyslog.dpkg-old
-rw-r--r-- 1 root root 269 Oct 28 2023 ubuntu-pro-client
-rw-r--r-- 1 root root 227 Nov 2 2023 ufw
-rw-r--r-- 1 root root 249 Nov 6 2023 unattended-upgrades
-rw-r--r-- 1 root root 164 Nov 2 2023 wtmp
Nowhere I see how logrotate even reads bolded file below:
error: Ignoring /etc/pihole/logrotate because the file owner is wrong (should be root or user with uid 0).
Once in the weekly cron job that runs the gravity update
In the log flush command
Please upload a debug log and post just the token URL that is generated after the log is uploaded by running the following command from the Pi-hole host terminal:
leonbrag@beachpi:~$ stat -c '%U %G' /var/log
root syslog
I also run verbose. Invoking log rotate always worked. I tried it before raising this issue.
But error happens on reboot and when it runs on schedule
leonbrag@beachpi:~$ sudo /usr/sbin/logrotate -v --state /var/lib/logrotate/pihole /etc/pihole/logrotate
reading config file /etc/pihole/logrotate
acquired lock on state file /var/lib/logrotate/piholeReading state from file: /var/lib/logrotate/pihole
Allocating hash table for state file, size 64 entries
Creating new state
Creating new state
Creating new state
Handling 3 logs
rotating pattern: /var/log/pihole/pihole.log after 1 days (1 rotations)
empty log files are not rotated, old logs are removed
considering log /var/log/pihole/pihole.log
Now: 2025-06-06 16:48
Last rotated at 2025-06-06 00:00
log does not need rotating (log has been rotated at 2025-06-06 00:00, which is less than a day ago)
rotating pattern: /var/log/pihole/FTL.log weekly (1 rotations)
empty log files are not rotated, old logs are removed
considering log /var/log/pihole/FTL.log
Now: 2025-06-06 16:48
Last rotated at 2025-06-06 00:00
log does not need rotating (log has been rotated at 2025-06-06 00:00, which is less than a week ago)
rotating pattern: /var/log/pihole/webserver.log weekly (3 rotations)
empty log files are not rotated, old logs are removed
considering log /var/log/pihole/webserver.log
Now: 2025-06-06 16:48
Last rotated at 2025-06-06 00:00
log does not need rotating (log has been rotated at 2025-06-06 00:00, which is less than a week ago)
leonbrag@beachpi:~$
root syslog is correct, credit to a good find by @rdwebdesign.
The environment that cron runs in is a very limited environment that can't be accurately duplicated via just a sudo call since that uses the current users environment (paths and environmen variables).
Let's try with the following command:
sudo su root -g syslog -c "/usr/sbin/logrotate --state /var/lib/logrotate/pihole /etc/pihole/logrotate"
total 16316
drwxr-xr-x 8 998 1006 4096 Jun 7 20:59 .
drwxr-xr-x 123 0 0 12288 Jun 7 08:35 ..
drwxr-xr-x 2 998 1006 4096 Jun 6 17:43 config_backups
-rw-r----- 1 998 1006 0 Jun 6 17:24 dhcp.leases
-rw-r----- 1 998 1006 6097 Jun 6 17:40 dnsmasq.conf
-rw-r----- 1 998 1006 11649024 Jun 6 17:35 gravity.db
drwxr-xr-x 2 998 1006 4096 Jun 6 17:24 gravity_backups
-rw-r----- 1 998 1006 94208 Jun 6 17:24 gravity_old.db
drwxr-xr-x 2 998 1006 4096 Jun 6 17:43 hosts
-rw-r----- 1 998 1006 401 Jun 6 17:24 install.log
drwxr-xr-x 2 998 1006 4096 Jun 6 17:24 listsCache
-rw-r----- 1 998 1006 445 Jun 6 17:24 logrotate
-rw-r----- 1 998 1006 3305472 Jun 6 17:24 macvendor.db
drwxr-xr-x 2 998 1006 4096 Jun 6 17:24 migration_backup
drwxr-xr-x 2 998 1006 4096 Jun 6 17:24 migration_backup_v6
-rw-r----- 1 998 1006 1523712 Jun 7 20:59 pihole-FTL.db
-rw-r----- 1 998 1006 55855 Jun 6 17:43 pihole.toml
-rw------- 1 998 1006 709 Jun 6 17:24 tls.crt
-rw------- 1 998 1006 1734 Jun 6 17:24 tls.pem
-rw------- 1 998 1006 737 Jun 6 17:24 tls_ca.crt
-rw-r--r-- 1 998 1006 323 Jun 7 16:32 versions
error: Ignoring /etc/pihole/logrotate because the file owner is wrong (should be root or user with uid 0).
acquired lock on state file /var/lib/logrotate/piholeReading state from file: /var/lib/logrotate/pihole
Allocating hash table for state file, size 64 entries
Creating new state
Creating new state
Creating new state
Handling 0 logs
The files are owned by UID 998 GID 1006. What kind of filesystem is that directory on?
There's a pihole-FTL startup script that owns the files in the /etc/pihole directory to the correct owner when FTL starts but that happens after the @reboot cronjob.
Let's try this:
sudo systemctl disable --now pihole-FTL.service
Then reboot that server, and then while FTL has not started yet:
sudo chown 0 0 /etc/pihole/logrotate
You can then re-enable FTL start on boot:
sudo systemctl enable --now pihole-FTL.service
A reboot after that would test if the logrotate file keeps the proper permissions after reboot.
