Comments
robert
/usr/sbin/clamav-unofficial-sigs.sh: line 1090: service: command not found
Kevin: That's interesting! Moving the content from /etc/incron.d/reproducer.conf to /var/spool/incron/root (via incrontab -e) seems indeed to solve this. No more zillions of incrond processes yet! May we get the same fix also for system wide /etc/incron.d/, please?
Important: The IN_NO_LOOP option still does no longer work, the example above creates endless loops with user incrontab (even it's overall better than before).
Kevin: Yes, quite reliable:
$ rpm -q incron
incron-0.5.12-9.el7.x86_64
$ for i in $(seq 1 250); do date > /var/www/html/${i}.txt; done
$ for i in $(seq 1 50); do mkdir -p /var/www/html/${i}; done
$ cat /etc/incron.d/reproducer.conf
/var/www/html/ IN_CLOSE_WRITE,IN_NO_LOOP /root/bin/update.sh "$@$#"
/var/www/html/10/ IN_CLOSE_WRITE,IN_NO_LOOP /root/bin/update.sh "$@$#"
$ cat /root/bin/update.sh
sed -e 's/2019/2020/g' -i "$1"
How to trigger the zillions of incrond processes that will eat the system sooner or later?
sed -e 's/1/2/' -i /var/www/html/100.txt
Afterwards I see lots of incrond processes and when doing nothing but waiting some time, I end up with zillions of incrond processes and load 1000 and when waiting even longer, the system crashes or ends with a kernel panic of khugepaged. Nevertheless the system is dead and needs a hard reset.
When starting incrond now, I see zillions of incrond processes and quite soon afterwards a load of 1000 and more. I did not see such a strange behaviour with incron-0.5.10-8.el7 before.
Please test https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-7b029e9ee8 as its successor.
Works here as expected (tested with private build of gramps-5.0.1-1.el7.noarch)
This update has been unpushed.
See https://bugzilla.redhat.com/show_bug.cgi?id=1435120#c15 (and further) for the planned future of gramps in EPEL 7. I'm unpushing this package, because it's anyway broken.
For me, incron 0.5.12 contains the regressions https://github.com/ar-/incron/issues/4 and https://github.com/ar-/incron/issues/32 (compared to 0.5.10 before).
Not sure how that "modular" stuff works. There was no special build/action/activity taken from maintainers perspective to get it into "modular", thus I won't take any special actions/activities here as well.
This update has been unpushed.
Please note that there is also redhat-release-workstation, thus redhat-release-server is not suitable itself as base for a requirement/conflict.
I am sorry, the update is totally broken (IMHO because redhat-release is not versioned):
[root@tux ~]# yum update epel-release
Loaded plugins: product-id, search-disabled-repos, security, subscription-manager
Setting up Update Process
Resolving Dependencies
--> Running transaction check
---> Package epel-release.noarch 0:6-8 will be updated
---> Package epel-release.noarch 0:6-9 will be an update
--> Processing Conflict: epel-release-6-9.noarch conflicts redhat-release >= 7
--> Finished Dependency Resolution
Error: epel-release conflicts with redhat-release-server-6Server-6.10.0.12.el6.x86_64
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest
[root@tux ~]#
[root@tux ~]# rpm -qa | grep redhat-release
redhat-release-server-6Server-6.10.0.12.el6.x86_64
[root@tux ~]#
[root@tux ~]# rpm -q --provides redhat-release-server-6Server-6.10.0.12.el6.x86_64
config(redhat-release-server) = 6Server-6.10.0.12.el6
redhat-release
system-release
redhat-release-server = 6Server-6.10.0.12.el6
redhat-release-server(x86-64) = 6Server-6.10.0.12.el6
[root@tux ~]#
Works as expected
@herrold, not sure what and how you tested exactly, but here:
/etc/init.d/nagios: Line 149: conditional binary operator expected
/etc/init.d/nagios: Line 149: Syntaxfehler beim unerwarteten Wort `!'
/etc/init.d/nagios: Line 149: ` if [[ test ! -f $NagiosRunFile; then'
Additionally:
clamav-unofficial-sigs.speccontains:However a few lines above there is:
It's actually hard to believe that this was tested, ever.