On Wed, 29 Jul 2020 20:54:38 +0800 Ed Greshko ed.greshko@greshko.com wrote:
So, dwatch is not part of Fedora.
Not now.
On an F31 system...
[egreshko@f31k ~]$ dnf info dwatch Last metadata expiration check: 0:00:33 ago on Wed 29 Jul 2020 08:49:46 PM CST. Error: No matching Packages to list
On an F32 system...
[egreshko@meimei ~]$ dnf info dwatch Last metadata expiration check: 4:12:49 ago on Wed 29 Jul 2020 04:35:59 PM CST. Error: No matching Packages to list
So, where did you acquire it?
https://koji.fedoraproject.org/koji/packageinfo?packageID=4453
Well, you should easily be able to tell if the hourly cron job runs...
journalctl -b 0 | grep hourly
should return a bunch of stuff like...
Jul 29 20:01:01 meimei.greshko.com CROND[29642]: (root) CMD (run-parts /etc/cron.hourly) Jul 29 20:01:01 meimei.greshko.com run-parts[29645]: (/etc/cron.hourly) starting 0anacron Jul 29 20:01:01 meimei.greshko.com run-parts[29651]: (/etc/cron.hourly) finished 0anacron
Returns nothing.
Then, just as a troubleshoot, have you tried running the system with setenforce 0?
I haven't, and that is a good suggestion. I'll reboot with setenforce=0 on the kernel boot line.
I updated the bugzilla with the new information, but putting enforcing=0 on the kernel boot line results in a working system again. The messages change to allowing crond to run even though it has a NULL security context because it is in security mode. I tried older kernels from when it worked before, they also fail now, so not a kernel problem. Somehow, the user that runs crond lost its selinux security context.
e.g.
crond[5954]: (*system*) NULL security context for user, but SELinux in permissive mode, continuing ()
and
crond[1169]: ((null)) No security context but SELinux in permissive mode, continuing (/etc/cron.d/dwatch)