Possible regression on RPM package from EPEL on EL7 #52
Comments
|
More testing has shown that the problem only occurs with user incrontab entries, the system incrontab entries in /etc/incron.d/ do not cause processes to be left in the zombie state. |
|
OK, didn't mean to close this! Still and issue, but at least I can work around it now. |
|
This was fixed in checkin f45c2f5 on 31 Oct 2017, but it's not in a formal release. |
|
I just downloaded the source RPM from EPEL and compared the sources, it appears that the EPEL package was built from sources that did not include the fix in that checkin. I will take the issue up with EPEL, thanks for the pointer! |
|
This just keeps getting better and better! I rebuilt the RPM using the current sources from Github and reinstalled, but the behaviour did not change, still getting zombies with every user incron event. I then deinstalled the packaged version and built and installed it from sources. I altered the systemd unit file to point to /usr/local/sbin/incron and started it up, no zombies. This seems to point to a difference in how they are being built, so I believe this is a packaging issue, which I will take up with EPEL. |
|
I've also had the same issue running the latest from EPEL on Centos 7. I downloaded the previous release and installed it (0.5.10-8.el7) and that seems to have "resolved" the issue.
Latest EPEL version: Working:
|
|
@jleafey Can you link the ticket you might open with EPEL? I'd like to keep an eye on it. |
|
The ticket number for this issue is 1656939 on Red Hat's Bugzilla system, which covers Fedora and EPEL as well as Red Hat's commercial products. https://bugzilla.redhat.com/show_bug.cgi?id=1656939 |
|
Just for reference, I hit the same bug. I tried moving the user incrontab to /etc/incron.d. That doesn't fix the problem. In my case, the zombie processes where gone but instead the child incron processes where created, but not zombied. So downgrade to 0.5.10 is the only workaround for now. And wait until the EPEL-ticket get's resolved. |
|
As a test I rebuilt incrond and incrontab from source and copied them over the files provided in the EPEL RPM (/usr/sbin/incrond and /usr/bin/incrontab). After restarting the daemon and running my test case again I have seen no defunct processes being generated at all. |
|
Fedora has new packages for 0.5.12 in the testing repository for EL7, Fedora 28, and Fedora 29 to include the no-zombie fix from upstream. The new packages are marked 0.5.12-9, the old package was 0.5.12-6. I have only tested it for a few hours but so far I have not seen another defunct process. Once I have tested it more extensively I will note the results here, but it looks good so far. |
|
I created issue today https://bugzilla.redhat.com/show_bug.cgi?id=1666590 ps ax | grep incron 0.5.12-9 from testing does not resolve my problem... :-( |
|
Glad I found this discussion. Current EPEL version is definitely broken. Caused some big headaches for us. Downgrading to 0.5.10 fixed it for now. That old version was not that easy to find. Apparently EPEL does not keep old versions around. |
|
I've experienced the same issue. 0.5.12-9 from testing did not fix it for me, either. 0.5.10 works for me. |
Stumbled upon that one, too! |
|
Tests made as part of the Bugzilla: 1666590 seems to fix the huge number of defuncts (0.5.12-6) or processes (0.5.12-9) in version 0.5.12-10. Thanks @philfry for the commit. |
|
EPEL stable shows v0.5.12-11 and we definitely have memory leak problems with that version. Downgrading to incron-0.5.10-8.el7.x86_64.rpm fixes it. So it appears there are still memory leak problems. |
|
So is this ever going to get fixed? |
|
Finally upgraded to 5.12.. After reviewing /var/log/cron, it appears that our old Comments lines were being interpreted as watch directories. removing the comments solved our problem. Hope this helps. |
|
This issue is also present in Debian Buster. Using armbian, based on Debian Buster, I have the problem. incron version installed is 5.12-1. I solved it by downgrading to 5.10. |
This is "fixed" in the VCS, just not in packages. Whether the package will be fixed only depends on whether incron, which looks quite dead, will ever see a new release. |
This bug is tracked in Debian's #930526. It only affects buster (oldstable), where it will likely never be fixed. |
|
Seeing as how this (pretty severe imo) bug will apparently never be fixed is it safe to say this package is abandonware? |
It would be so sad. Incron is a wonderful package, and a key piece of the software we are developing. |
On several RHEL and CentOS 7 systems we just updated from 0.5.10 to 0.5.12 via the package from the EPEL repository. Since then we have started getting a large number of defunct processes that are children of the incron daemon. Each and every time a particular script runs a "zombie" process is left with the parent PID pointing to the incron daemon.
The incrontab entry in question is as follows:
/oracle/hbanpr/jobs/output IN_CLOSE_WRITE,recursive=false /home/oracle/bin/cp_to_volshare.sh $@/$#I added "recursive=false" to the line after reading some recent posts on the network. When I look at the zombie processes in the /proc filesystem they have no open files. The script itself is pretty simple, it merely copies the file triggering the event to another location and it works just fine if I invoke it from the command line.
Short of restarting incrond periodically to flush out the defunct processes, is there something else I can do to resolve this?
The text was updated successfully, but these errors were encountered: