Still logrotate error

Hi folks,
any help on this issue: Log rotate error - #7

I just don't understand how this file even invoked by logrotate.

This is content of

leonbrag@beachpi:/etc/pihole$ sudo cat /etc/logrotate.conf

# 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).

It is called a few places.

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:

pihole -d

or if you run your Pi-hole as a Docker container:

docker exec -it <pihole-container-name-or-id> pihole -d

where you substitute <pihole-container-name-or-id> as required.

https://tricorder.pi-hole.net/tOUzC3FP/

You are running on older versions of Pi-hole, you should update.

-rw-r--r-- 1 pihole pihole 319 Jun  6 05:14 /etc/pihole/versions
   CORE_VERSION=v6.0.6
   CORE_BRANCH=master
   CORE_HASH=0f7803b7
   GITHUB_CORE_VERSION=v6.1.2
   GITHUB_CORE_HASH=ec892ec0
   WEB_VERSION=v6.1
   WEB_BRANCH=master
   WEB_HASH=1eaddca8
   GITHUB_WEB_VERSION=v6.2.1
   GITHUB_WEB_HASH=cc1cc285
   FTL_VERSION=v6.1
   FTL_BRANCH=master
   FTL_HASH=a3313229
   GITHUB_FTL_VERSION=v6.2.2
   GITHUB_FTL_HASH=044ef46d

I am seeing a manual edit to:

 -rw-r----- 1 root root 364 Apr 25 14:20 /etc/pihole/logrotate
   /var/log/pihole/pihole.log {
   	su root syslog
   	daily
   	copytruncate
   	rotate 1
   	compress
   	delaycompress
   	notifempty
   	nomail
   }
   /var/log/pihole/FTL.log {
   	su root syslog
   	weekly
   	copytruncate
   	rotate 1
   	compress
   	delaycompress
   	notifempty
   	nomail
   }
+   /var/log/pihole/webserver.log {
+  su root syslog
   weekly
   copytruncate
   rotate 3
   compress
   delaycompress
   notifempty
   nomail
   }

The file should read as:

-rw-r----- 1 root root 439 Apr 16 02:46 /etc/pihole/logrotate
   /var/log/pihole/pihole.log {
       su root root
       daily
       copytruncate
       rotate 5
       compress
       delaycompress
       notifempty
       nomail
   }
   /var/log/pihole/FTL.log {
       su root root
       weekly
       copytruncate
       rotate 3
       compress
       delaycompress
       notifempty
       nomail
   }
   /var/log/pihole/webserver.log {
       su root root
       weekly
       copytruncate
       rotate 3
       compress
       delaycompress
       notifempty
       nomail
   

Note the two lines that are different in your setup.

There's another line that shows the init system is shutting down Pi-hole:

  2025-06-06 05:12:02.901 PDT [1084M] INFO: Asked to terminate by "/sbin/init fixrtc splash" (PID 1, user root UID 0)

I'm not sure what that process is.

Thank you for looking into.

  1. reboot as 5:12 expected. I have cron job that reboots machine daily at 5:12am
  2. Indeed, su root syslog strange. I saw it too. But because I never manually edited this file, i left it as is.

I will:

  1. update pihole
  2. edit file back to su root root, if it's still wrong after reboot

@DanSchaper - I did pihole -r
I then ran pihole -up to make sure it's latest.

The logorate file still incorrect. No idea why:

leonbrag@beachpi:/etc/pihole$ sudo cat logrotate  | grep su
        su root syslog
        su root syslog
su root syslog

I will manually revert to root root

and after editing file to su root root and after rebooting I still got the same error!

I took new logs here: https://tricorder.pi-hole.net/Qxosmg3g/

The su ... line is initially just a comment (# su #):

And this code replaces it with the actual values:

What is the output of stat -c '%U %G' /var/log in your system?

When are you seeing this error message?

The file doesn't have the last stanza indented, I'm not sure if that's contributing to the problem.

Lets run that logrotate command manually,

su root -c "/usr/sbin/logrotate --state /var/lib/logrotate/pihole /etc/pihole/logrotate"

and then

sudo cat /var/lib/logrotate/pihole

That will show the filename and last timestamp.

I see it during reboot, due to this line:

I could not run your cmd exactly, since su root asks for password which does not exist (I believe). But this ran:

leonbrag@beachpi:~$ sudo /usr/sbin/logrotate --state /var/lib/logrotate/pihole /etc/pihole/logrotate
leonbrag@beachpi:~$ sudo cat /var/lib/logrotate/pihole
logrotate state -- version 2
"/var/log/pihole/webserver.log" 2025-6-6-0:0:1
"/var/log/pihole/FTL.log" 2025-6-6-0:0:1
"/var/log/pihole/pihole.log" 2025-6-6-0:0:1
leonbrag@beachpi:~$
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:~$

this is after reboot (when error is generated and emailed to me by root):

leonbrag@beachpi:~$ sudo cat /var/lib/logrotate/pihole
logrotate state -- version 2
"/var/log/pihole/webserver.log" 2025-6-6-0:0:1
"/var/log/pihole/FTL.log" 2025-6-6-0:0:1
"/var/log/pihole/pihole.log" 2025-6-6-0:0:1

I idented last stanza, no errors running this:

sudo /usr/sbin/logrotate -v --state /var/lib/logrotate/pihole /etc/pihole/logrotate

But reboot is still error! Very perplexing

this is how email looks:

I fully uninstalled pihole, rebooted, fresh install pihole. error still there.

by looking at time stamp, I can see that was created at the time of new install, so not my old:

-rw-r----- 1 root root 445 Jun 6 17:24 logrotate

this is how su statements look. I did not touch this file.
So if it's wrong, then this is how it is installed:

leonbrag@beachpi:/etc/pihole$ sudo cat logrotate | grep su
    su root syslog
    su root syslog
    su root syslog

Maybe its just a bug on all system, it just my system configured to email cron errors

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"

No errors.

I'm running in to dead ends here.

Can you edit /etc/cron.d/pihole and modify the first @reboot line:

- @reboot root /usr/sbin/logrotate --state /var/lib/logrotate/pihole /etc/pihole/logrotate
+ @reboot root ls -lan /etc/pihole && /usr/sbin/logrotate --verbose --state /var/lib/logrotate/pihole /etc/pihole/logrotate

That adds in an ls -lan /etc/pihole to get a listing of what the directory looks like at the time of the call, and adds a --verbose flag to logrotate.

Maybe that will show the issue.

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

Okay, that's what I was looking for!

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.

Thanks. I will try later tonight. However can I understand what is a root cause ? Especially since it’s happened again when I reinstalled clean.

This is raspberry pi board (the smallest one they sell I think). It’s has micosd card

Welcome to Ubuntu 24.04.2 LTS (GNU/Linux 6.8.0-1028-raspi aarch64)
leonbrag@beachpi:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
tmpfs            41M  3.0M   39M   8% /run
/dev/mmcblk0p2  117G  4.0G  109G   4% /
tmpfs           205M  3.4M  202M   2% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
/dev/mmcblk0p1  253M  184M   69M  73% /boot/firmware
log2ram         128M   27M  102M  21% /var/log
tmpfs            41M   12K   41M   1% /run/user/1001
leonbrag@beachpi:~$

So why are the user id and group id not set to zero by the install?
And will I have to go through the same step on upgrade?

I think what Dan above is asking for is output for below?

findmnt /