Additionally: clamav-unofficial-sigs.spec contains:

%attr(0755,clamupdate,clamupdate) %dir %{_localstatedir}/lib/%{name}
%attr(0755,clamupdate,clamupdate) %dir %{_localstatedir}/log/%{name}

However a few lines above there is:

getent group clam-update >/dev/null || groupadd -r clam-update
getent passwd clam-update >/dev/null || \
    useradd -r -g clam-update -d %{_localstatedir}/lib/%{name} -s /bin/bash \
    -c "%{name} user account" clam-update
exit 0

It's actually hard to believe that this was tested, ever.

BZ#1683646 Please build latest clamav-unofficial-sigs for EPEL 6
/usr/sbin/ 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
$ 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/ "$@$#"
/var/www/html/10/ IN_CLOSE_WRITE,IN_NO_LOOP /root/bin/ "$@$#"
$ cat /root/bin/
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.


Works here as expected (tested with private build of gramps-5.0.1-1.el7.noarch)

BZ#1662501 Please build python3-bsddb3 for EPEL 7
BZ#1663442 Rename Request: python-bsddb3 - Python 3 bindings for Berkeley DB

This update has been unpushed.


See (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 and (compared to 0.5.10 before).

BZ#1650654 incorrect permissions on /usr/lib/systemd/system/incrond.service

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.

User Icon robert commented & provided feedback on epel-release-6-9 4 years ago

Please note that there is also redhat-release-workstation, thus redhat-release-server is not suitable itself as base for a requirement/conflict.

BZ#1645568 epel-release: lock to matching RHEL release
User Icon robert commented & provided feedback on epel-release-6-9 4 years ago

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-
 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
[root@tux ~]# 
[root@tux ~]# rpm -q --provides redhat-release-server-6Server-
config(redhat-release-server) = 6Server-
redhat-release-server = 6Server-
redhat-release-server(x86-64) = 6Server-
[root@tux ~]# 
BZ#1645568 epel-release: lock to matching RHEL release

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'