🚨 Filebeat Error Guide: 'data path already locked by another beat' — Fix a Contended path.data

Overview

Filebeat refuses to start when another process already holds the lock on its data directory, and exits immediately with:

Exiting: data path already locked by another beat. Please make sure that multiple beats are not sharing the same data path (path.data).

Every Beat takes an exclusive lock (filebeat.lock) on its path.data directory at startup. The lock exists so two Filebeat processes can never share one registry — if they did, they would fight over read offsets and produce duplicate or missing data. When Filebeat sees the directory is already locked, it does the safe thing and exits rather than corrupting state. The message means one of two things: a second Filebeat really is running against that directory, or a previous instance died without releasing the lock and left it stale.

Symptoms

• Filebeat exits within a second of starting; the service crash-loops under systemd.
• Logs show data path already locked by another beat and nothing else useful.
• systemctl status filebeat flaps between activating and failed.
• A manual foreground run fails while the systemd unit is (or was) also running.
• Two units or containers point at the same host path for path.data.
• The unit restarts repeatedly and never reaches steady active (running).

Common Root Causes

• Two Filebeat instances, one data path — a systemd service and a manual filebeat -e run at the same time.
• Multiple containers sharing a host volume — several Filebeat containers bind-mounting the same path.data.
• Copy-paste config drift — two units with different config files but the same path.data.
• Stale lock after a hard kill — SIGKILL, OOM, or power loss left filebeat.lock behind with no live process.
• Overlapping systemd + cron/manual starts during troubleshooting.

How to diagnose

First confirm whether a live Filebeat actually holds the lock:

ps -ef | grep -i '[f]ilebeat'
sudo systemctl status filebeat

Find what is holding the lock file, if anything:

sudo lsof /var/lib/filebeat/filebeat.lock 2>/dev/null
ls -la /var/lib/filebeat/filebeat.lock

Check that no two units or containers point at the same path.data:

grep -R 'path.data' /etc/filebeat/ 2>/dev/null
sudo systemctl cat filebeat | grep -i 'path.data\|ExecStart'
docker ps --filter ancestor=elastic/filebeat --format '{{.Names}}'   # if containerized

If lsof shows a live PID, you have a genuine duplicate. If it shows nothing but the lock file exists, it is stale.

Fixes

Case 1 — a duplicate instance is really running. Stop the extra one and keep a single owner of the data path:

sudo systemctl stop filebeat        # stop the service before any manual run
ps -ef | grep '[f]ilebeat'          # confirm nothing else is left
sudo systemctl start filebeat       # start exactly one

Never run filebeat -e by hand while the service is active — that is the most common cause.

Case 2 — separate Beats need separate data paths. Give each instance its own directory:

# instance A — /etc/filebeat/filebeat.yml
path.data: /var/lib/filebeat

# instance B — /etc/filebeat/filebeat-app2.yml
path.data: /var/lib/filebeat-app2

Case 3 — containers must not share path.data. Give each container its own volume, not a shared host path:

# docker-compose.yml (sanitized)
services:
  filebeat:
    image: elastic/filebeat:8.14.0
    volumes:
      - filebeat_data:/usr/share/filebeat/data   # named per-instance volume
volumes:
  filebeat_data:

Case 4 — stale lock, no live process. Only after lsof/ps prove nothing is running, remove the stale lock and start clean:

sudo systemctl stop filebeat
ps -ef | grep '[f]ilebeat'                       # must be empty
sudo rm -f /var/lib/filebeat/filebeat.lock       # remove ONLY when no process holds it
sudo systemctl start filebeat

What to watch out for

• Never delete filebeat.lock while a Filebeat process is alive — you invite two writers on one registry and duplicate ingest.
• Two units with the same path.data will alternately win the lock; give every Beat a unique data directory.
• A crash-looping unit can mask the real error — read the first failure line, not the repeated restarts.
• In Kubernetes, a DaemonSet with a hostPath data volume plus a stray second pod on the node will collide; scope the volume per pod.
• Removing the lock does not fix the underlying duplicate — find and stop the second instance too.

Related

• Filebeat Error Guide: could not start registrar
• Filebeat Error Guide: registry file is corrupt
• Filebeat Error Guide: input states not finished

More configuration walkthroughs live in the Filebeat guides.