[Bug 1670047] New: xtables.lock is not removed

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(a)redhat.com
          Reporter: balwierz(a)gmail.com
        QA Contact: extras-qa(a)fedoraproject.org
                CC: perl-devel(a)lists.fedoraproject.org, ppisar(a)redhat.com
  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.