wazuh-db: ERROR:

1,503 views
Skip to first unread message

Nie Einerda

unread,
Mar 18, 2024, 9:37:44 AM3/18/24
to Wazuh | Mailing List
Hi @all,
have an issue with OMV Wazuh setup concerning wazuh-db:
Since moving quite a lot of agents (about 120) frm a default to another group I get DB errors within ossec.log:
wazuh-db: ERROR: DB(064) sqlite3_prepare_v2() stmt(86): no such table: sync_info
wazuh-db: ERROR: DB(065) sqlite3_prepare_v2(): no such table: metadata
wazuh-db: ERROR: DB(065) sqlite3_prepare_v2() stmt(46): no such table: scan_info
wazuh-db: ERROR: DB(065) Cannot cache statement
wazuh-analysisd: ERROR: FIM decoder: Bad response from database: Cannot save fim control message
wazuh-db: ERROR: DB(065) sqlite3_prepare_v2() stmt(88): no such table: sync_info

I alreday tried to restore earliest backup available and at first all looks good. after moving again agents from default to another group above error is returning.
Any advice how to solve this issue?
Thanks you

Christian Borla

unread,
Mar 18, 2024, 9:56:54 AM3/18/24
to Wazuh | Mailing List
Hi Nie Einerda
I hope you are well!

What Wazuh version do you have?
Could you share how many groups and the exact process that are you following?
I don't know if the concept move group is correct, usually you create a group, and add the agents to that group, then the agent can belong to 2 groups or more, prioritizing the configuration of one or another. 
example https://documentation.wazuh.com/current/user-manual/reference/tools/agent-groups.html#agent-groups
Regards.

Nie Einerda

unread,
Mar 18, 2024, 10:39:22 AM3/18/24
to Wazuh | Mailing List
thanks Christian.
I'm on wazuh 4.7.3. Not sure if the issue is related to re-grouping about 100 agents from default group into another.
Overall I've setup 12 groups. In generall I avoid putting agents in multible groups.
A few days before I also updatded wazuh OVA wazuh 4.7.2 to 4.7.3. This also might have been the time where DB issue started.
as a DB restore did not fix it, my question would be how a restoration could done manually. (did not find sth within wazuh docs)
Regards

Christian Borla

unread,
Mar 18, 2024, 3:08:50 PM3/18/24
to Wazuh | Mailing List

Hi Nie Einerda

1. Backup the current database: Before making any changes, ensure to backup the current database in case anything goes wrong during the restoration process.

2. Stop Wazuh services: It's important to stop Wazuh services before manipulating the database to avoid potential data corruption. 
sudo systemctl stop wazuh-manager

3. Replace the database: Find the backup copy of the database you want to restore and rename it to match the name of the current database. 

4. Start Wazuh services: After replacing the database, you can start Wazuh services.
sudo systemctl start wazuh-manager

Did you check the examples about adding groups?
Also if you can reproduce it easily, you can enable debug level 2 in the internal_options.conf file, and restart the manager, this way we will have more information about what may be happening.
Regards.

Nie Einerda

unread,
Mar 19, 2024, 4:24:39 AM3/19/24
to Wazuh | Mailing List
I'm afraid, but you did not understand my problem: I' dont have an vaild backup, all exisiting are corrupt as they produce same errors. So my question is:
how could a restoration or a rebuild of the DB done manually?

I can't find this case within Wazuh documentation at all.

Pls let me know.
Thanks

Christian Borla

unread,
Mar 19, 2024, 7:57:52 AM3/19/24
to Wazuh | Mailing List
Hi Nie Einerda
Sorry, yes I got it now.

1. To check for corruption yo can use the SQLite command line tool to run integrity checks on your database file. You can do this by running the following command:
sqlite3 your_database.db "PRAGMA integrity_check;"

2. or rebuild indexes, Indexes in SQLite can sometimes become corrupted, you can try rebuilding them using the following command:
sqlite3 your_database.db "VACUUM;"

3. Last option I think is to use the SQLite recovery tool

Always stoping the Wazuh services before run any sqlite command.
Let me know if that helps.
Regards 

Nie Einerda

unread,
Mar 20, 2024, 4:20:06 AM3/20/24
to Wazuh | Mailing List
Meanwhile, the issue could be fixed:
I followed your instructions to check DB health.
There was no finding which led me to the error messages itself. 
DB(064) sqlite3_prepare_v2(): and DB(065) sqlite3_prepare_v2(): pointed to the respective agent IDs /064/065). I just removed them via manage_agents and re-added again.
this solved the issue.
Nevertheless, thanks for pointing out to use sqlite3 for checking DB health.

Regards
Reply all
Reply to author
Forward
0 new messages