Source: puppetdb Version: 6.2.0-3 Severity: normal This package ships two log rotation mechanisms for /var/log/puppetdb/puppetdb.log:
root@pauli:~# dpkg -L puppetdb | grep log /etc/puppetdb/logback.xml /etc/puppetdb/request-logging.xml /usr/share/doc/puppetdb/changelog.Debian.gz /var/log /var/log/puppetdb /etc/logrotate.d/puppetdb This creates noise when logrotate comes at night to try rotating the logs: /etc/cron.daily/logrotate: error: destination /var/log/puppetdb/puppetdb-access.log.1 already exists, renaming to /var/log/puppetdb/puppetdb-access.log.1-2019030706.backup error: error setting owner of /var/log/puppetdb/puppetdb-access.log.1 to uid 119 and gid 125: Operation not permitted error: destination /var/log/puppetdb/puppetdb.log.1 already exists, renaming to /var/log/puppetdb/puppetdb.log.1-2019030706.backup error: error setting owner of /var/log/puppetdb/puppetdb.log.1 to uid 119 and gid 125: Operation not permitted run-parts: /etc/cron.daily/logrotate exited with return code 1 It also marks the service as "degraded" in systemd, just for good measure. A workaround is to not ship a logrotate.d file at all, and it's the approach DSA has taken to solve the issue so far: https://salsa.debian.org/dsa-team/mirror/dsa-puppet/commit/e31d91af7a8a5d9b90bc309e38067605c00d7f13 ... but I wonder if we would rather not ship `logback.xml`, to follow POLA (Principle Of Least Astonishment). That config file is: 1. XML, and therefore not quite human readable 2. non-standard, as far as basic Linux sysadmin work is concerned (it might be "standard" in the Java world, but looks like gibberish to me) So I would suggest to not let PuppetDB rotate its own logs unless there's a good reason to do so in the first place. But in either case, we shouldn't do *both*. PS: after investigation, I noticed this bug (#881584) was declared fixed in 4.4.1-3, but that's not really accurate: the bug won't be present on new installs, but on upgrade, the old config file sticks around. So you need to somehow remove that config file on upgarde, but I would still argue against using the logback.xml mechanism and instead revert to using the logrotate one. -- System Information: Debian Release: 10.1 APT prefers stable APT policy: (500, 'stable'), (1, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE=fr_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled