🚨 Telegraf Error Guide: '[inputs.procstat] open /var/run/myapp.pid: no such file or directory' — Fix Process Matching

Overview

The procstat input collects per-process metrics (CPU, memory, threads, file descriptors) for processes you select. When you match by pid_file and that file is missing, the plugin logs the open failure straight from the OS:

2026-07-12T12:00:00Z E! [inputs.procstat] Error in plugin: open /var/run/myapp.pid: no such file or directory

A closely related form appears when the PID file exists but points at a process that has already exited, so the lookup finds nothing:

E! [inputs.procstat] Error in plugin: pid 4821 does not exist

Telegraf keeps running, but no procstat_* metrics are produced for the targeted process until it can be matched.

Symptoms

• procstat metrics for a specific service are missing while other inputs report normally.
• journalctl -u telegraf repeats open <path>.pid: no such file or directory every collection interval.
• The application runs fine (systemctl status myapp is active) but Telegraf still cannot find its PID.
• The PID file path in the config no longer matches where the app or its packaging writes it.
• Metrics appear only intermittently — the PID file exists during runs but is deleted on restart/rotation.

Common Root Causes

• Wrong pid_file path — the config points at /var/run/myapp.pid but the app writes to /run/myapp/myapp.pid or /var/lib/myapp/pid.
• Process not running — the service is stopped or crashed, so no PID file was ever written.
• Stale/removed PID file — the app was started without writing a PID file, or the file is cleaned on shutdown while Telegraf still polls.
• Permissions on the PID file — the file exists but the telegraf user cannot read it (owned by root with 0600).
• App started without a PID file at all — many systemd services no longer write PID files, so pid_file matching is inherently fragile.
• Path moved by packaging — an upgrade relocated the runtime directory (/var/run symlinked to /run), leaving the old path in the config.

Diagnostic Workflow

First confirm whether the PID file actually exists and whether the process is running at all:

# Does the PID file exist and is it readable by telegraf?
ls -l /var/run/myapp.pid
sudo -u telegraf cat /var/run/myapp.pid

# Find the real process another way
pgrep -a -f myapp
systemctl show -p MainPID --value myapp

Then run only the procstat input under Telegraf to confirm it matches after a fix:

telegraf --config /etc/telegraf/telegraf.conf --test --input-filter procstat --debug

Rather than depend on a fragile PID file, prefer matching by systemd_unit, pattern, or exe. A systemd_unit match is the most robust for services managed by systemd:

[[inputs.procstat]]
  systemd_unit = "myapp.service"
  pid_finder = "native"

To match by command-line pattern (works even without systemd), use pattern:

[[inputs.procstat]]
  pattern = "myapp --config"
  pid_finder = "native"

If you must keep the PID file, correct the path and confirm the app writes it. On modern systems /var/run is a symlink to /run:

[[inputs.procstat]]
  pid_file = "/run/myapp/myapp.pid"

You can also match by executable name or cgroup for containerized workloads:

[[inputs.procstat]]
  exe = "myapp"
  # or, for cgroup-scoped matching:
  # cgroup = "systemd/system.slice/myapp.service"

Example Root Cause Analysis

After a package upgrade, myapp process metrics vanished and Telegraf logged open /var/run/myapp.pid: no such file or directory every interval, even though systemctl status myapp was active. ls -l /var/run/myapp.pid returned “No such file” — the new package shipped a systemd unit with Type=simple that no longer writes a PID file at all.

Rather than force the app to write a PID file, the team switched the config from pid_file = "/var/run/myapp.pid" to systemd_unit = "myapp.service" and set pid_finder = "native". On the next run, telegraf --test --input-filter procstat printed CPU and memory metrics again. The lesson: pid_file matching breaks whenever packaging or systemd changes; matching by systemd_unit (or pattern/exe) tracks the process regardless of whether a PID file exists.

Prevention Best Practices

• Prefer systemd_unit, pattern, or exe matching over pid_file; PID files are the most brittle selector.
• If you use pid_file, point at /run/... (the canonical path) and confirm the app is actually configured to write it.
• Ensure the PID file is readable by the telegraf user, or avoid PID files entirely to sidestep permission issues.
• Keep pid_finder = "native" for portability; it avoids depending on the external pgrep binary.
• Alert on absent procstat metrics for critical services so a stopped process or bad selector is caught quickly.
• Review procstat selectors after every package upgrade that could relocate runtime directories or change the systemd unit type.

Quick Command Reference

# Check the PID file and its readability
ls -l /var/run/myapp.pid
sudo -u telegraf cat /var/run/myapp.pid

# Find the process without a PID file
pgrep -a -f myapp
systemctl show -p MainPID --value myapp

# Run only the procstat input with debug
telegraf --config /etc/telegraf/telegraf.conf --test --input-filter procstat --debug

# Watch procstat errors live
journalctl -u telegraf -f | grep -i procstat

Related Guides

• Telegraf [inputs.exec] exit status 1
• Telegraf [inputs.tail] permission denied
• Telegraf [inputs.docker] docker.sock permission denied

More fixes in the Telegraf guides.

Conclusion

[inputs.procstat] open <path>.pid: no such file or directory means the PID file you told Telegraf to read is not there — because the process is stopped, the path is wrong, or the app never writes a PID file. Confirm the file and the process with ls and systemctl show -p MainPID, then switch to a durable selector like systemd_unit, pattern, or exe. Matching the process directly rather than through a fragile PID file keeps procstat metrics flowing across restarts and upgrades.