Bug 1148627 brought my attention to the file /var/cache/dnf/…/hawkey.log. I have two questions: 1. Is there any particular reason this log isn't placed in /var/log like all other logs. It would be much easier to find there. 2. Is this log not meant to be rotated/cleaned in any way? On my system it is currently well over 100MB, and seems to reach back almost a year. What about adding a /etc/logrotate.d/hawkey to rotate this at some convenient interval?
Hi Goran, good point, but this log is a bit tricky. "hawkey.log" is in sack's cache dir for each sack so the data are not merged from multiple sources. The depsolving output from libsolv should not be mixed by other proceses (PackageKit) to get valid debug info. The other usecase is when dnf developers ask users to compress and upload metadata cache dir we'll also get this log so we can see if sack was properly loaded.
Log file added to dnf logrotate script
dnf-0.6.3-2.fc21,dnf-plugins-core-0.1.4-1.fc21,hawkey-0.5.2-1.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/dnf-0.6.3-2.fc21,dnf-plugins-core-0.1.4-1.fc21,hawkey-0.5.2-1.fc21
Package dnf-0.6.3-2.fc21, hawkey-0.5.2-1.fc21, dnf-plugins-core-0.1.4-1.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing dnf-0.6.3-2.fc21 hawkey-0.5.2-1.fc21 dnf-plugins-core-0.1.4-1.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-16760/dnf-0.6.3-2.fc21,dnf-plugins-core-0.1.4-1.fc21,hawkey-0.5.2-1.fc21 then log in and leave karma (feedback).
dnf-0.6.3-2.fc21, hawkey-0.5.2-1.fc21, dnf-plugins-core-0.1.4-1.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
This causes selinux alerts on my system: Additional Information: Source Context system_u:system_r:logrotate_t:s0-s0:c0.c1023 Target Context unconfined_u:object_r:rpm_var_cache_t:s0 Target Objects /var/cache/dnf [ dir ] Source logrotate Source Path /usr/sbin/logrotate Port <Unknown> Host edamame.cdg.redhat.com Source RPM Packages logrotate-3.8.7-4.fc21.x86_64 Target RPM Packages Policy RPM selinux-policy-3.13.1-99.fc21.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name edamame.cdg.redhat.com Platform Linux edamame.cdg.redhat.com 3.17.6-300.fc21.x86_64 #1 SMP Mon Dec 8 22:29:32 UTC 2014 x86_64 x86_64 Alert Count 4 First Seen 2014-12-15 11:29:01 CET Last Seen 2014-12-18 03:07:01 CET Local ID 08461e48-944d-4368-a9ed-3c4a590526d8 Raw Audit Messages type=AVC msg=audit(1418868421.889:1592): avc: denied { read } for pid=30264 comm="logrotate" name="dnf" dev="dm-2" ino=1191052 scontext=system_u:system_r:logrotate_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:rpm_var_cache_t:s0 tclass=dir permissive=0 type=SYSCALL msg=audit(1418868421.889:1592): arch=x86_64 syscall=openat success=no exit=EACCES a0=ffffffffffffff9c a1=7fff17251b30 a2=90800 a3=0 items=0 ppid=30262 pid=30264 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=142 comm=logrotate exe=/usr/sbin/logrotate subj=system_u:system_r:logrotate_t:s0-s0:c0.c1023 key=(null) Hash: logrotate,logrotate_t,rpm_var_cache_t,dir,read
Yes, I also got this AVC. And I plan to report that too. But even after locally creating an SELinux module to allow that access, the log still doesn't get rotated. I'm trying to figure out why, before I make more reports.
The AVC was reported, by Ankur Sinha, not me, in bug 1163438. The confusion I had about the log still not being rotated I believe is because of a mistake in the logrotate configuration for dnf. It applies to all logs dnf rotates, and I've filed a separate bug 1177394 about that.