Closed logicwonder closed 1 month ago
The failed_auth
ets table is created when mod_fail2ban is started, and it is deleted when the module is stopped and is not running in any other vhost in ejabberd.
When a client authenticates correctly, any row related to its IP address is removed in that table.
Looking at your error message, it appears when a client authenticates correctly, and the module tries to remove the row from the table. However, it seems the table does not exist at all.
I wonder: does that ets table exist or not? You can check it by entering ejabberdctl live shell attached to your ejabberd node:
$ ejabberdctl debug
(ejabberd@localhost)1> ets:info(failed_auth).
[{id,#Ref<0.2980915192.329908227.29410>},
{decentralized_counters,false},
{read_concurrency,false},
{write_concurrency,false},
{compressed,false},
{memory,305},
{owner,<0.1107.0>},
{heir,<0.881.0>},
{name,failed_auth},
{size,0},
{node,ejabberd@localhost},
{named_table,true},
{type,set},
{keypos,1},
{protection,public}]
ets tables are local, not clustered like mnesia tables. That table should exist in each of your ejabberd nodes, and it may contain different data in each node.
You can view the table content. In my case, my server got only one authetnication failure:
(ejabberd@localhost)2> ets:tab2list(failed_auth).
[{{0,0,0,0,0,65535,32512,1},1,1714044872774,20}]
When you disable the module and restart ejabberd, is the table removed?
When you enable the module again and restart ejabberd, is the table created?
Apologising for my late reply.
When you disable the module and restart ejabberd, is the table removed?
Yes
When you enable the module again and restart ejabberd, is the table created?
Out of three nodes, the table got created back only in the third node. The module is reverted to dsabled in node1 and node 2. Tried enabling and disabling multiple times in two nodes but the table is not getting created.
See the command output below:
(ejabberd@node1)1> ets:tab2list(failed_auth).
** exception error: bad argument
in function ets:match_object/2
called as ets:match_object(failed_auth,'_')
*** argument 1: the table identifier does not refer to an existing ETS table
in call from ets:tab2list/1 (ets.erl, line 771)
(ejabberd@node2)1> ets:tab2list(failed_auth).
** exception error: bad argument
in function ets:match_object/2
called as ets:match_object(failed_auth,'_')
*** argument 1: the table identifier does not refer to an existing ETS table
in call from ets:tab2list/1 (ets.erl, line 771)
(ejabberd@node3)1> ets:tab2list(failed_auth).
[{{0,0,0,0,0,65535,10857,62538},1,1716022340131,20}]
I removed the problematic nodes from cluster, and isolated the nodes. Then Mnesia was cleared and restarted after enabling mod_fail2ban. It was observed that the ets:tab2list table got recreated. The nodes were then joined back to the cluster. The problem got resolved.
Thanks @badlop for providing the scripts for checking the issue.
Environment
Errors from error.log/crash.log
Bug description
I am running an eJbberd cluster with 3 nodes. For testing purpose, the mod_fail2ban module was disabled in ejabberd.yml and configuration was reloaded in all the three nodes.
After a day, the module was enabled back in ejabberd.yml for all the three nodes and reloaded. Since that point, I am observing the above errors continuously. The error disappears in the node when mod_fail2ban is disabled.
Please help.