AWS wodle cloudwatchlogs/inspector database locked issue

[Rahul Manoj]

Hi Team,

We are facing repeated SQLite locking issues with the AWS wodle in Wazuh. Logs are coming up from various buckets but when it comes to services the below errors are coming up. Can someone find a fix for the below issue?

Environment:

Wazuh version: 4.14.5
AWS services used:
  cloudwatchlogs
  inspector
 
Multiple AWS profiles configured:
  default
  Gov

Logs from ossec.log:

2026/05/21 11:32:24 wazuh-modulesd:aws-s3: INFO: Executing Bucket Analysis: (Bucket: yyy-xxxx-vpc-flowlog, Type: vpcflow, Profile: default)
2026/05/21 11:32:30 wazuh-modulesd:aws-s3: INFO: Executing Bucket Analysis: (Bucket: zxzx-bbbb-evironment-vpc-flow-logs-zzzz, Type: vpcflow, Profile: default)
2026/05/21 11:32:34 wazuh-modulesd:aws-s3: INFO: Executing Bucket Analysis: (Bucket: xxxx-firewall-vpc-yyy, Type: vpcflow, Profile: default)
2026/05/21 11:32:36 wazuh-modulesd:aws-s3: INFO: Executing Bucket Analysis: (Bucket: xxxx-yyyy-vpc-flowlog-govcloud, Type: vpcflow, Profile: Gov)
2026/05/21 11:32:40 wazuh-modulesd:aws-s3: INFO: Executing Service Analysis: (Service: cloudwatchlogs, Profile: default)
2026/05/21 11:32:48 wazuh-modulesd:aws-s3: WARNING: Service: cloudwatchlogs  -  Returned exit code 12
2026/05/21 11:32:48 wazuh-modulesd:aws-s3: WARNING: Service: cloudwatchlogs  -  database is locked
2026/05/21 11:32:48 wazuh-modulesd:aws-s3: INFO: Executing Service Analysis: (Service: cloudwatchlogs, Profile: Gov)
2026/05/21 11:33:02 wazuh-modulesd:aws-s3: WARNING: Service: cloudwatchlogs  -  Returned exit code 12
2026/05/21 11:33:02 wazuh-modulesd:aws-s3: WARNING: Service: cloudwatchlogs  -  database is locked
2026/05/21 11:33:02 wazuh-modulesd:aws-s3: INFO: Executing Service Analysis: (Service: inspector, Profile: Gov)
2026/05/21 11:39:33 wazuh-modulesd:aws-s3: WARNING: Service: inspector  -  Returned exit code 12
2026/05/21 11:39:33 wazuh-modulesd:aws-s3: WARNING: Service: inspector  -  database is locked
2026/05/21 11:39:33 wazuh-modulesd:aws-s3: INFO: Fetching logs finished.


the below mentioned configuration is written in ossec.conf for aws service:

    <service type="cloudwatchlogs">
      <aws_profile>default</aws_profile>
      <aws_log_groups>/aws/lambda/sns-alert-log-lf</aws_log_groups>
      <regions>us-east-1</regions>
      <only_logs_after>2026-May-20</only_logs_after>
    </service>
   
    <service type="cloudwatchlogs">
      <aws_profile>Gov</aws_profile>
      <aws_log_groups>/aws/lambda/sns-alert-log-govcloud</aws_log_groups>
      <only_logs_after>2026-May-20</only_logs_after>
    </service>
   
    <service type="inspector">
      <aws_profile>Gov</aws_profile>
      <only_logs_after>2026-May-20</only_logs_after>
    </service>
   

Thanks.

[Jorge Eduardo Molas]

Hi,

The "database is locked" error (exit code 12) in the AWS module occurs when the SQLite database used by the wodle to track already-processed log entries is held by another process at the time cloudwatchlogs and inspector attempt to access it. Your VPC Flow bucket analyses succeed because they run earlier in the execution sequence and complete before the lock contention occurs.

There are two likely root causes:

1. Interval overtaken (most likely): Your inspector service takes over 6 minutes to complete (11:33:02 → 11:39:33). If the configured <interval> for the AWS shorter than the total execution time of all services combined, the next scheduled run starts before the current one finishes. The new execution finds the database still locked by the previous inspector run.
2. Stale journal file from a crashed execution: A previous run that was interrupted left a .db-journal file that keeps the SQLite database locked even though no process is actively using it.

• Step 1 — Check whether multiple instances of the module are running simultaneously:

ps aux | grep -i aws | grep -v grep

​

         If you see more than one Python process for the AWS module, this confirms the interval overtaken scenario.

• Step 2 — Stop the Wazuh manager:

systemctl stop wazuh-manager

​

• Step 3 — Check for stale journal files in the wodles directory:

ls -la /var/ossec/wodles/aws/​

  If any file ends in .db-journal, remove it:

rm -f /var/ossec/wodles/aws/*.db-journal

​

•   Step 6 (Preventive — address interval overtaken): Review the <interval> value set in the <wodle name="aws-s3"> block of /var/ossec/etc/ossec.conf and compare it against he observed execution time. Given that inspector alone takes over 6 minutes, the total run time across all your services and buckets is likely well above that. Set the interval to a value safely above the total observed execution time:

<wodle name="aws-s3"> <interval>30m</interval> <!-- adjust based on observed total run time --> ... </wodle>

​

After restarting, monitor /var/ossec/logs/ossec.log for the next execution cycle and confirm the services complete without the database error. To help confirm which of the two root causes applies in your case, share the output of the ps aux check above and the <interval> value currently set in your configuration.

References:

• Monitoring AWS services — Troubleshooting
• CloudWatch Logs service configuration