Logstash file input sincedb_path interoperability with pipeline restart offset recovery

Direct answers

1. Priority: Logstash uses the explicitly configured sincedb_path exclusively. It does not fall back to the default $HOME/.sincedb_* location when that path is set.
2. Replaced or cleared sincedb: If the mounted sincedb file is missing, empty, or replaced between restarts, the file input treats it as a fresh database and reads all matched files from start_position (default: beginning). The last saved offset is not retained.
3. Write interval impact: The default sincedb_write_interval: 15 creates a durability window of up to 15 seconds. On clean shutdown (SIGTERM) Logstash flushes immediately, eliminating the gap. On unclean termination (OOMKill, SIGKILL, power loss) up to one interval of processed bytes can be lost, causing duplicate events on restart.

How offset recovery works

On startup the file input reads the sincedb file at the configured path. Each record stores the watched file's path, inode, major device number, minor device number, and the last known byte offset. Logstash scans the current filesystem for files matching the input's path patterns and matches them against the sincedb entries by inode + device (Unix) or file ID (Windows).

• Match found: the saved offset is honored and reading resumes from that byte position.
• No match (new file, rotated file with new inode, sincedb cleared): the plugin falls back to start_position.
• Permission changes that do not alter inode/device do not reset the offset.

File rotation is handled naturally: the old file's final offset remains recorded; the new file (same path, new inode) starts from start_position.

Container deployment requirements

• The sincedb_path must point to a persistent volume that survives pod/container restarts.
• The volume must be mounted before the Logstash process starts (use an initContainer or startupProbe if needed).
• The same UID/GID should own the sincedb file across restarts to avoid permission errors that prevent writes.
• Do not share a single sincedb file across multiple Logstash instances — they will overwrite each other's offsets.

Verification steps

1. Check startup logs for sincedb_path set to /your/path and Reading sincedb from /your/path.
2. Inspect the sincedb content: cat /your/path/sincedb (plain text: path, inode, major, minor, offset). Compare before and after a restart.
3. Simulate unclean shutdown: write logs, kill -9 <pid>, restart, and observe whether the last events before the kill are duplicated.
4. Test rotation: mv watched.log watched.log.1 && touch watched.log, write to both, restart, and confirm the rotated file's offset is preserved while the new file starts from the beginning.

One diagnostic detail

Are you using a network filesystem (NFS, SMB, EFS, etc.) for the sincedb volume? Network filesystems may not preserve inode/device stability across server restarts, which breaks sincedb matching and forces re-reading from the beginning.