[Bug 1392] nft stalls on EAGAIN upon repeatedly flushing and populating a set

[bugzilla-daemon at netfilter.org]

https://bugzilla.netfilter.org/show_bug.cgi?id=1392

--- Comment #5 from kfm at plushkava.net ---
(In reply to Timo Sigurdsson from comment #4)
> I think I experienced the same or a similar issue once and I also couldn't
> reproduce it. I once got a message from nft saying it failed to allocate
> memory. I think it was during a run of `nft -cf' for my script containing
> the ipv6 bogons set.

As it happens, I have been able to reproduce it many times since. I allowed the
script that I wrote to refresh my (IPv4) bogons set to run periodically, even
though it doesn't work well. The method employed is similar to the attached
script. That is, it tries to empty the set then add the new elements in a
single pass. It runs at 4 hour intervals and generates the "No space left on
device" about 5 or 6 times a day.

Not only that, but it regularly triggers the following errors:

    Error: interval overlaps with an existing one
    Error: Could not process rule: File exists

For reference, my set definition is as follows:

    set bogons {
        type ipv4_addr
        flags interval,timeout
        auto-merge
        timeout 4h5m
    }

The intent was to try to work around the initial inability to reliably update
sets atomically by instead mimicking the behaviour of "ipset -exist add". Of
course, it doesn't work properly. Nothing works. The only effect was to expose
myself to additional bugs, some of which I ought to file but the sheer range of
issues that I encountered has greatly diminished my motivation of late.

In short, I can discern no viable method of:

1) atomically updating a set without reloading the entire ruleset (if it even
is atomic)
2) adding elements that may or may not already exist without errors and/or
side-effects

In the case of ipset, the first approach is rendered trivial due to the
existence of the "swap" command and the second works precisely as designed and
documented.

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20200703/4457b41e/attachment.html>