https://bugzilla.redhat.com/show_bug.cgi?id=1670047 Bug ID: 1670047 Summary: xtables.lock is not removed Product: Fedora Version: 29 Hardware: x86_64 OS: Linux Status: NEW Component: perl-IPTables-libiptc Severity: medium Assignee: ppisar@xxxxxxxxxx Reporter: balwierz@xxxxxxxxx QA Contact: extras-qa@xxxxxxxxxxxxxxxxx CC: perl-devel@xxxxxxxxxxxxxxxxxxxxxxx, ppisar@xxxxxxxxxx Target Milestone: --- Classification: Fedora Description of problem: IPTables-libiptc perl module does not deal with xtables lock file (/run/xtables.lock) properly. Upon a call of IPTables::libiptc::init() a lock file is created. But this lock file is not removed after commit(). It is actually being recreated after each iptables_do_command() call. As a result, any script using this module will get stuck on the second invocation of iptables_do_command, as the lock file will be already created at this time. It will wait forever for a release of this lock file which would never happen. Version-Release number of selected component (if applicable): 0.52-27.fc29 How reproducible: Always Steps to Reproduce: 1.a) Run the simple perl code: use IPTables::libiptc; my $filter = IPTables::libiptc::init('filter'); $filter->commit(); #an empty commit 2.a) ls /run/xtables.lock 1.b) If you add iptables_do_command() the script will never finish: $| = 1; use IPTables::libiptc; my $filter = IPTables::libiptc::init('filter'); print "debug: after init\n"; $filter->iptables_do_command(['--flush', "OUTPUT"]); print "debug: after the first flush\n"; $filter->iptables_do_command(['--flush', "OUTPUT"]); # a wait occurs here print "debug: after the second flush\n"; $filter->commit(); Actual results: a) Lock file persists after the script has finished. b) Lock file prevents script from being finished. The messages printed: debug: after init debug: after the first flush Another app is currently holding the xtables lock; still -9s 0us time ahead to have a chance to grab the lock... Another app is currently holding the xtables lock; still -19s 0us time ahead to have a chance to grab the lock... [...] Expected results: No self-locking behaviour. xtables.lock removed after all objects called ->commit() or the script has finished. Additional info: - From my inspection perl-IPTables-libiptc has the most recent patch against iptables 1.6.1, which is older than 1.8.0 shipped with FC29. - There was no such problem in FC26 which ships older iptables 1.6.x - The same version is in rawhide, but I have not tested it -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ perl-devel mailing list -- perl-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to perl-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@xxxxxxxxxxxxxxxxxxxxxxx
