$ findmnt /
TARGET SOURCE FSTYPE OPTIONS
/ /dev/mmcblk0p2 ext4 rw,relatime,discard,errors=remount
I dont see anything awkward except maybe for the errors=remount option which seems not to be a valid option according to my Debain man page:
$ man mount
[..]
relatime
Update inode access times relative to modify or change time.
Access time is only updated if the previous access time was
earlier than the current modify or change time. (Similar to
noatime, but it doesn’t break mutt(1) or other applications
that need to know if a file has been read since the last time
it was modified.)
Since Linux 2.6.30, the kernel defaults to the behavior
provided by this option (unless noatime was specified), and the
strictatime option is required to obtain traditional semantics.
In addition, since Linux 2.6.30, the file’s last access time is
always updated if it is more than 1 day old.
[..]
discard
If set, causes discard/TRIM commands to be issued to the block
device when blocks are freed. This is useful for SSD devices
and sparse/thinly-provisioned LUNs.
[..]
errors={panic|continue|remount-ro}
Specify FAT behavior on critical errors: panic, continue
without doing anything, or remount the partition in read-only
mode (default behavior).
But that should not be related to the issue ... I think 
This is vanilla Ubuntu install on Pi. I did not manually adjust any mounting options
Had to lookup how but do you know about Linux kernel auditing?
$ apt show auditd
Package: auditd
Version: 1:3.0.9-1
[..]
Description: User space tools for security auditing
The audit package contains the user space utilities for
storing and searching the audit records generated by
the audit subsystem in the Linux 2.6 kernel.
.
Also contains the audit dispatcher "audisp".
$ sudo apt install auditd
[..]
After this operation, 934 kB of additional disk space will be used.
$ arch
x86_64
$ sudo auditctl -a always,exit -F arch=x86_64 -F path=/etc/pihole/logrotate -F perm=wa -k pihole_logrotate
$
$ sudo ausearch -ts today -k pihole_logrotate
----
time->Tue Jun 10 18:51:28 2025
type=PROCTITLE msg=audit(1749574288.670:106): proctitle=617564697463746C002D6100616C776179732C65786974002D460061726368007838365F3634002D460070617468002F6574632F7069686F6C652F6C6F67726F74617465002D46007065726D007761002D6B007069686F6C655F6C6F67726F74617465
type=SYSCALL msg=audit(1749574288.670:106): arch=c000003e syscall=44 success=yes exit=1096 a0=4 a1=7ffe4ac38360 a2=448 a3=0 items=0 ppid=221638 pid=221639 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts3 ses=1620 comm="auditctl" exe="/usr/sbin/auditctl" subj=unconfined key=(null)
type=CONFIG_CHANGE msg=audit(1749574288.670:106): auid=1000 ses=1620 subj=unconfined op=add_rule key="pihole_logrotate" list=4 res=1
$ sudo touch /etc/pihole/logrotate
$
$ sudo ausearch -ts today -k pihole_logrotate
----
time->Tue Jun 10 18:51:28 2025
type=PROCTITLE msg=audit(1749574288.670:106): proctitle=617564697463746C002D6100616C776179732C65786974002D460061726368007838365F3634002D460070617468002F6574632F7069686F6C652F6C6F67726F74617465002D46007065726D007761002D6B007069686F6C655F6C6F67726F74617465
type=SYSCALL msg=audit(1749574288.670:106): arch=c000003e syscall=44 success=yes exit=1096 a0=4 a1=7ffe4ac38360 a2=448 a3=0 items=0 ppid=221638 pid=221639 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts3 ses=1620 comm="auditctl" exe="/usr/sbin/auditctl" subj=unconfined key=(null)
type=CONFIG_CHANGE msg=audit(1749574288.670:106): auid=1000 ses=1620 subj=unconfined op=add_rule key="pihole_logrotate" list=4 res=1
----
time->Tue Jun 10 18:59:34 2025
type=PROCTITLE msg=audit(1749574774.090:168): proctitle=746F756368002F6574632F7069686F6C652F6C6F67726F74617465
type=PATH msg=audit(1749574774.090:168): item=1 name="/etc/pihole/logrotate" inode=132416 dev=ca:02 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
type=PATH msg=audit(1749574774.090:168): item=0 name="/etc/pihole/" inode=131673 dev=ca:02 mode=040775 ouid=999 ogid=1001 rdev=00:00 nametype=PARENT cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
type=CWD msg=audit(1749574774.090:168): cwd="/home/dehakkelaar"
type=SYSCALL msg=audit(1749574774.090:168): arch=c000003e syscall=257 success=yes exit=3 a0=ffffff9c a1=7ffff3fbe7e7 a2=941 a3=1b6 items=2 ppid=221727 pid=221728 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts4 ses=1631 comm="touch" exe="/usr/bin/touch" subj=unconfined key="pihole_logrotate"
Could check before and after install
EDIT: Cleanup:
$ sudo auditctl -l
-a always,exit -F arch=b64 -S all -F path=/etc/pihole/logrotate -F perm=wa -F key=pihole_logrotate
$ sudo auditctl -D
No rules
They are:
install -o root -g root -D -m 644 -T "${PI_HOLE_LOCAL_REPO}"/advanced/Templates/logrotate ${target}
But if the file already exists then it is modified in place with a number of sed calls.
Does that change to the logrotate file stick on reboot? If you reboot without automatically starting pihole-FTL (the systemctl disable pihole-FTL command) does that file stay or revert back to UID 998 GID 1006? ls -la /etc/pihole should show that and also show what the username groupname is instead of just the ID numbers. You need to make sure that it happens before pihole-FTL starts because the script that starts that daemon will take ownership of the files that it needs to and we need to see the ownership immediately on reboot.
If it reverts then we need to look at a possible read-only filesystem issue.
0:0 change persisted after reboot
But error is still reported on reboot !
I'm just guessing here, but maybe this is related to log2ram:
leonbrag@beachpi:~$ df -h
Filesystem Size Used Avail Use% Mounted on
(...)
log2ram 128M 27M 102M 21% /var/log
I'm not sure if log2ram changes ownership when copying the files from disk to tmpfs mount.
What user is 998? What group is 1006?
Can you post the full output of that modified cron @reboot job that shows the full directory listing?
total 28800
drwxr-xr-x 8 998 1006 4096 Jun 10 14:57 .
drwxr-xr-x 123 0 0 12288 Jun 10 06:41 ..
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 11964416 Jun 8 03:27 gravity.db
drwxr-xr-x 2 998 1006 4096 Jun 8 03:27 gravity_backups
-rw-r----- 1 998 1006 11649024 Jun 6 17:35 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 8 03:27 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 2437120 Jun 10 14:57 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 10 12:29 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 stateLast login: Tue Jun 10 14:55:42 2025 from 172.16.2.2194
leonbrag@beachpi:~$ getent passwd 998
pihole:x:998:1006::/home/pihole:/usr/sbin/nologin
leonbrag@beachpi:~$ getent group 1006
pihole:x:1006:
leonbrag@beachpi:~$
That file has reverted the chown back to the user ownership and not root.
This is a problem on the system end, either there is a process that is modifying the files or there is a read-only situation happening.
The warning from the cron job is correct and should be happening as long as that file keeps reverting back any changes that are being made to it.
If want to figure out which above process (if none of the logs will show), you'd have to make that auditctl rule reboot persistent like below:
$ arch
x86_64
$ sudo nano /etc/audit/rules.d/pihole_logrotate.rules
-a always,exit -F arch=x86_64 -F path=/etc/pihole/logrotate -F perm=wa -k pihole_logrotate
$ sudo reboot
$ sudo auditctl -l
-a always,exit -F arch=b64 -S all -F path=/etc/pihole/logrotate -F perm=wa -F key=pihole_logrotate
If I test:
$ date; sudo touch /etc/pihole/logrotate
Wed Jun 11 05:50:38 AM CEST 2025
$ sudo ausearch -ts today -k pihole_logrotate
[..]
time->Wed Jun 11 05:50:38 2025
[..]
type=SYSCALL ... pid=651 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts3 ses=3 comm="touch" exe="/usr/bin/touch"
EDIT: Check below two man pages for what above ones do:
man auditctl
man ausearch
1 Like
I created this tmpfile.d config:
z /etc/pihole/logrotate 0644 0 0 -
I verified that change above persist. but there is race condition between tmpfiles and cron running.
so I introduced sleep 60 in pihole cron file.
this fixed the problem. I understand it not addressing root cause.
buy maybe @DanSchaper pinhole can consider introducing sleep 60 in its cron file. Such delay may stagger tasks on reboot.
Why write "su root root"?
Won't just "su root" do the same thing?
I thought that the syntax was "su -root root," but I could be wrong.
Man page:
$ man logrotate.conf
[..]
su user group
Rotate log files set under this user and group instead of us‐
ing default user/group (usually root). user specifies the
user used for rotation and group specifies the group used for
rotation (see the section USER AND GROUP for details). If
the user/group you specify here does not have sufficient
privilege to make files with the ownership you've specified
in a create directive, it will cause an error. If logrotate
runs with root privileges, it is recommended to use the su
directive to rotate files in directories that are directly or
indirectly in control of non-privileged users.
@deHakkelaar why does not PiHole create regular logrotate config file under /etc/logrotate.d ?
I was thinking of you just the other day. Logrotate should solve your problem with running out of space. Instead of logs going on forever, a new log is started (say) every week. Old logs are zipped and numbered sequentially, with the current log being #1. You decide how many logs you want to keep, and older logs are deleted. Every parameter is configurable. The default zipping program is gzip, which should be already available. Doug.
Are you referring to below bit?
Yes you could.
But in the case of Unbound, I'd rather have systemd-journald.service do the logging and maintenance.
I dont know.
I'm not a developer
My guess its more suitable for the Docker container.
@DanSchaper - why not use regular logrotate.conf ?
@deHakkelaar - not why it impact docker container in any way.