On 5/16/24 16:05, Andy Pieters wrote:
E.g. in your running iptables / firewall
Don't think this is a bug of ipset, but rather of running config.
Suggest you try to shut down firewalld/iptables prior to stopping ipset
Thanks for the reply,
Yes, a full reboot on 6.9.1 update allowed everything to come back up fine.
(iptables, fail2ban, ipset).
What prompted the concern was this was one of the only occasions I know of
in using Arch since 2009 (and I guess since the init-script/systemd change)
where "systemctl restart <package>" doesn't restart the package cleanly.
That's why I wanted to inquire further.
I can see the kernel complaining that it has set X in use and that causing
the restart to fail, but nowhere did I see any indication that a restart of
ipset would cause a fail2ban shutdown as well. (it may inherently make sense
if fail2ban depends on ipset, but ipset is simply listed as an 'optdepends'
for fail2ban)
So an ipset restart triggering a fail2ban shutdown was concerning. I guess
we chock it up to a one-off sequence of update and restart event. It wasn't
like it was hard to figure out and recover from, the only lingering concern it
why was it necessary to begin with.
--
David C. Rankin, J.D.,P.E.
