Comments

367 Comments
/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.

karma

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.

karma

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.

karma

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.

karma

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).

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 5 years ago
karma

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 5 years ago
karma

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 ~]# 
BZ#1645568 epel-release: lock to matching RHEL release
karma

Works as expected

karma

@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'
User Icon robert commented & provided feedback on gpsd-3.16-2.el7 7 years ago
karma
$ gpscat /dev/ttyUSB2 
Traceback (most recent call last):
  File "/bin/gpscat", line 9, in <module>
    import gps.packet as sniffer
ImportError: No module named gps.packet
$ 

Starts working after manual yum install gpsd-libs, so missing run-time dependency.