Description of problem: After some poking around upon discovering that /var/log/messages had grown to ~200M, contained entries going back more than a year, and hadn't been rotated for about as long, I discovered that rotation stopped working at some point due to rsyslog-logrotate not being installed. While installing rsyslog-logrotate fixed the problem, this is a subtle and nasty "gotcha" from upgrading to F38 from previous versions. Version-Release number of selected component (if applicable): Unknown. How reproducible: Unknown. Steps to Reproduce: 1. Upgrade from a version of Fedora in which rsyslog-logrotate doesn't exist to one in which it does? (I don't recall exactly what versions I've upgraded through, but I've probably performed multiple upgrades that skipped a release.) Actual results: /var/log/messages starts to grow without bound. Expected results: rsyslog-logrotate should be automatically installed during the upgrade in order to prevent this change in behavior.
It's a packaging matter, not something dnf can help with.
I was trying to file this as an upgrade bug. (BTW, those instructions seem to be broken.) By all means, please reassign as appropriate. I'm not sure I'm convinced this is fixable just by package metadata, but... 🤷
Also noticed /var/log/messages stopped rotating since april 2022 when a quick search in the file was slow... as it had grown to 10GB :| The log format doesn't even include the year so I wasn't sure which April it was at first! Anyway, sure, the rsyslog package already "recommends" rsyslog-logrotate but that's not enough obviously. And we wouldn't want to make that a require otherwise there'd be no point in splitting the package in the first place. Might want to bring it up on the forum to see if there's a way to do this, I'm not sure there's a good way short of making it a require for a release or two so that everyone upgrading gets the package then drop down to recommend, but even then new installs wouldn't get it would they? alpine's apk has a logic for "Install this if package A and B are both present", but I'm not aware of anything similar for dnf... Frankly I'd just ship in the logrotate file and drop the logrotate dependency if that was a problem -- the file is harmless if left alone...
My suggestion is to include the logrotate file in the base package as it was in the past but leave the logrotate dependency part of the rsyslog-logrotate package. What do you think?
Thank you for coming back to this! This (moving file back without the logrotate dependency) sounds good to me, happy to review spec change/test the new rpm when it's out. For comparison I've just looked at /etc/logrotate.d contents on my system and it appears to be what most packages do: ``` for f in /etc/logrotate.d/*; do pkg=$(rpm -qf $f) || continue; echo "$f: $pkg"; rpm -q --requires "$pkg" | grep -i logrotate; done /etc/logrotate.d/bootlog: plymouth-22.02.122-5.fc39.x86_64 /etc/logrotate.d/btmp: logrotate-3.21.0-4.fc39.x86_64 config(logrotate) = 3.21.0-4.fc39 /etc/logrotate.d/chrony: chrony-4.4-1.fc39.x86_64 /etc/logrotate.d/dnf: dnf-data-4.17.0-6.fc39.noarch /etc/logrotate.d/dpkg: dpkg-1.21.21-2.fc39.x86_64 /etc/logrotate.d/firebird: firebird-4.0.3.2975-1.fc39.x86_64 /etc/logrotate.d/firewalld: firewalld-2.0.1-1.fc39.noarch /etc/logrotate.d/ganesha: nfs-ganesha-5.7-1.fc39.x86_64 /etc/logrotate.d/glusterfs: glusterfs-fuse-11.0-5.fc39.x86_64 /etc/logrotate.d/iodine-client: iodine-client-0.8.0-2.fc39.x86_64 /etc/logrotate.d/iodine-server: iodine-server-0.8.0-2.fc39.x86_64 /etc/logrotate.d/iscsiuiolog: iscsi-initiator-utils-iscsiuio-6.2.1.9-17.gitc26218d.fc39.x86_64 /etc/logrotate.d/libreswan: libreswan-4.11-1.fc39.1.x86_64 logrotate /etc/logrotate.d/libvirtd: libvirt-daemon-9.7.0-1.fc39.x86_64 /etc/logrotate.d/libvirtd.qemu: libvirt-daemon-driver-qemu-9.7.0-1.fc39.x86_64 /etc/logrotate.d/lightdm: lightdm-1.32.0-5.fc39.x86_64 /etc/logrotate.d/lighttpd: lighttpd-1.4.71-2.fc39.x86_64 /etc/logrotate.d/mariadb: mariadb-server-10.5.22-1.fc39.x86_64 /etc/logrotate.d/munge: munge-0.5.15-5.fc39.x86_64 logrotate /etc/logrotate.d/numad: numad-0.5-41.20150602git.fc39.x86_64 /etc/logrotate.d/ppp: ppp-2.5.0-3.fc39.x86_64 /etc/logrotate.d/prometheus-node-exporter: golang-github-prometheus-node-exporter-1.5.0-2.fc39.x86_64 /etc/logrotate.d/psacct: psacct-6.6.4-19.fc39.x86_64 /etc/logrotate.d/rsyslog: rsyslog-logrotate-8.2310.0-1.fc39.x86_64 config(rsyslog-logrotate) = 8.2310.0-1.fc39 logrotate >= 3.5.2 /etc/logrotate.d/samba: samba-common-4.19.0-1.fc39.noarch /etc/logrotate.d/snapper: snapper-0.10.4-2.fc39.x86_64 /etc/logrotate.d/sssd: sssd-common-2.9.2-1.fc39.x86_64 /etc/logrotate.d/thttpd: thttpd-2.29-15.fc39.x86_64 /etc/logrotate.d/tor: tor-0.4.8.7-1.fc39.x86_64 /etc/logrotate.d/wpa_supplicant: wpa_supplicant-2.10-8.fc39.x86_64 /etc/logrotate.d/wtmp: logrotate-3.21.0-4.fc39.x86_64 config(logrotate) = 3.21.0-4.fc39 /etc/logrotate.d/xen: xen-runtime-4.17.2-2.fc39.x86_64 ``` So out of 29 packages (excluding rsyslog and logrotate itself), all of them are part of the main package or some -common/-data shared subpackage, and only two depend on logrotate -- I guess it's fair to say that shouldn't cause problem.
(In reply to Dominique Martinet from comment #5) > Thank you for coming back to this! > > This (moving file back without the logrotate dependency) sounds good to me, > happy to review spec change/test the new rpm when it's out. > > For comparison I've just looked at /etc/logrotate.d contents on my system > and it appears to be what most packages do: > ``` > for f in /etc/logrotate.d/*; do pkg=$(rpm -qf $f) || continue; echo "$f: > $pkg"; rpm -q --requires "$pkg" | grep -i logrotate; done > /etc/logrotate.d/bootlog: plymouth-22.02.122-5.fc39.x86_64 > /etc/logrotate.d/btmp: logrotate-3.21.0-4.fc39.x86_64 > config(logrotate) = 3.21.0-4.fc39 > /etc/logrotate.d/chrony: chrony-4.4-1.fc39.x86_64 > /etc/logrotate.d/dnf: dnf-data-4.17.0-6.fc39.noarch > /etc/logrotate.d/dpkg: dpkg-1.21.21-2.fc39.x86_64 > /etc/logrotate.d/firebird: firebird-4.0.3.2975-1.fc39.x86_64 > /etc/logrotate.d/firewalld: firewalld-2.0.1-1.fc39.noarch > /etc/logrotate.d/ganesha: nfs-ganesha-5.7-1.fc39.x86_64 > /etc/logrotate.d/glusterfs: glusterfs-fuse-11.0-5.fc39.x86_64 > /etc/logrotate.d/iodine-client: iodine-client-0.8.0-2.fc39.x86_64 > /etc/logrotate.d/iodine-server: iodine-server-0.8.0-2.fc39.x86_64 > /etc/logrotate.d/iscsiuiolog: > iscsi-initiator-utils-iscsiuio-6.2.1.9-17.gitc26218d.fc39.x86_64 > /etc/logrotate.d/libreswan: libreswan-4.11-1.fc39.1.x86_64 > logrotate > /etc/logrotate.d/libvirtd: libvirt-daemon-9.7.0-1.fc39.x86_64 > /etc/logrotate.d/libvirtd.qemu: > libvirt-daemon-driver-qemu-9.7.0-1.fc39.x86_64 > /etc/logrotate.d/lightdm: lightdm-1.32.0-5.fc39.x86_64 > /etc/logrotate.d/lighttpd: lighttpd-1.4.71-2.fc39.x86_64 > /etc/logrotate.d/mariadb: mariadb-server-10.5.22-1.fc39.x86_64 > /etc/logrotate.d/munge: munge-0.5.15-5.fc39.x86_64 > logrotate > /etc/logrotate.d/numad: numad-0.5-41.20150602git.fc39.x86_64 > /etc/logrotate.d/ppp: ppp-2.5.0-3.fc39.x86_64 > /etc/logrotate.d/prometheus-node-exporter: > golang-github-prometheus-node-exporter-1.5.0-2.fc39.x86_64 > /etc/logrotate.d/psacct: psacct-6.6.4-19.fc39.x86_64 > /etc/logrotate.d/rsyslog: rsyslog-logrotate-8.2310.0-1.fc39.x86_64 > config(rsyslog-logrotate) = 8.2310.0-1.fc39 > logrotate >= 3.5.2 > /etc/logrotate.d/samba: samba-common-4.19.0-1.fc39.noarch > /etc/logrotate.d/snapper: snapper-0.10.4-2.fc39.x86_64 > /etc/logrotate.d/sssd: sssd-common-2.9.2-1.fc39.x86_64 > /etc/logrotate.d/thttpd: thttpd-2.29-15.fc39.x86_64 > /etc/logrotate.d/tor: tor-0.4.8.7-1.fc39.x86_64 > /etc/logrotate.d/wpa_supplicant: wpa_supplicant-2.10-8.fc39.x86_64 > /etc/logrotate.d/wtmp: logrotate-3.21.0-4.fc39.x86_64 > config(logrotate) = 3.21.0-4.fc39 > /etc/logrotate.d/xen: xen-runtime-4.17.2-2.fc39.x86_64 > ``` > > So out of 29 packages (excluding rsyslog and logrotate itself), all of them > are part of the main package or some -common/-data shared subpackage, and > only two depend on logrotate -- I guess it's fair to say that shouldn't > cause problem. That's awesome and thanks for the quick feedback. In case of Fedora rawhide, the PR can be found at https://src.fedoraproject.org/rpms/rsyslog/pull-request/42 . The scratch-build is at https://koji.fedoraproject.org/koji/taskinfo?taskID=111285253 . Later I will do some preliminary testing as well.
FEDORA-2024-173eee07b1 has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2024-173eee07b1
FEDORA-2024-173eee07b1 has been pushed to the Fedora 40 stable repository. If problem still persists, please make note of it in this bug report.