Logstash file input sincedb_path interoperability with pipeline restart offset recovery

In current Logstash releases, the file input plugin maintains a sincedb checkpoint to track byte offsets per file path, resuming from saved positions upon pipeline restart. When sincedb_path is configured to an externally mounted volume, the interoperability between the configured checkpoint location and the pipeline's offset recovery mechanism becomes critical for data integrity in containerized environments.

The precise goal is to determine how Logstash reconciles a persistently mounted sincedb_path against file inode changes, rotations, or permission shifts during restart, and whether the saved byte offset is honored or reset to the file start. Key uncertainty arises from the default sincedb_write_interval of 15 seconds, which may create a temporal gap between actual pipeline progress and persisted offset, especially under high-write frequency. Additionally, if the sincedb file at the configured path is unavailable or altered between restarts, Logstash may default to beginning-of-file processing, potentially emitting duplicate events or losing records.

Does Logstash prioritize the configured sincedb_path over the default state directory when resuming from a checkpoint? If the externally mounted sincedb_path is replaced or cleared between restarts, does the file input reset to the beginning of associated files or retain the last saved offset? What impact does the sincedb_write_interval have on offset durability versus temporary staleness when the checkpoint resides on a persistent volume?