ipset v7.21 update - package stop / start exits with failure - but ipset is still running?
Devs, ipset was updated after a recent minor bug with save was fixed. The updated package was installed today. Restarting fails with an error code due to: May 16 14:14:31 valkyrie ipset[62200]: ipset v7.21: Set cannot be destroyed: it is in use by a kernel component May 16 14:14:31 valkyrie systemd[1]: ipset.service: Control process exited, code=exited, status=1/FAILURE The start process then fails: May 16 14:14:31 valkyrie ipset[62203]: ipset v7.21: Error in line 1: Set cannot be created: set with the same name already exists May 16 14:14:31 valkyrie systemd[1]: ipset.service: Main process exited, code=exited, status=1/FAILURE The result is fail2ban is left shutdown after the attempted stop of ipset and its failure to start. Is this a new bug, or is something else wrong? -- David C. Rankin, J.D.,P.E.
On Thu, 16 May 2024 at 21:45, David C. Rankin <drankinatty@gmail.com> wrote:
Devs,
ipset was updated after a recent minor bug with save was fixed. The updated package was installed today. Restarting fails with an error code due to:
May 16 14:14:31 valkyrie ipset[62200]: ipset v7.21: Set cannot be destroyed: it is in use by a kernel component May 16 14:14:31 valkyrie systemd[1]: ipset.service: Control process exited, code=exited, status=1/FAILURE
It just means that there is a reference to one of the sets.
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
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.
participants (2)
-
Andy Pieters
-
David C. Rankin