in_tail fails silently when SQLite DB is locked (offset update failure) #11416
Description
Bug Report
Describe the bug
When using the in_tail plugin with a database configured (db parameter), if the SQLite database becomes locked (e.g., receives SQLITE_BUSY or SQLITE_LOCKED), the plugin silently fails to update the file offset. The function flb_tail_db_file_offset returns -1, but no error message is logged to indicate that the persistence failed.
To Reproduce
- Configure
in_tailwith a db path. - Ensure the SQLite database file is locked by an external process (e.g., holding an exclusive lock).
- Generate log data that Fluent Bit tails.
- Fluent Bit will process the logs but fail to update the offset in the DB.
- Kill Fluent Bit.
- Restart Fluent Bit.
- Observe that Fluent Bit re-ingests the logs that were processed during the locked state because the offset was never saved.
Expected behavior
Fluent Bit should log an error (e.g., [error] [input:tail:tail.0] db: cannot update file offset...) when it fails to update the database. This allows operators to be aware of the persistence failure and potential data duplication upon restart.
Screenshots
N/A
Your Environment
- Version used: Master / Latest
- Environment name and version (e.g. Kubernetes? What version?): N/A
- Server type and version: N/A
- Operating System and version: N/A
- Filters and plugins:
in_tail
Additional context
This silent failure leads to unexpected data duplication. If the DB is locked for an extended period, a significant volume of logs may be re-ingested upon restart without any warning in the logs that the offsets were not being saved. The fix involves checking the return code of sqlite3_step and logging an error if it is not SQLITE_DONE.