🚨 Telegraf Error Guide: '[inputs.exec] executable file not found in $PATH' — Fix Exec Command Paths

Overview

The exec input runs an external command each interval and parses its stdout into metrics. When Telegraf cannot locate the command on the service’s PATH, the Go exec package fails before the script ever runs and the plugin logs the lookup error:

2026-07-12T12:00:00Z E! [inputs.exec] Error in plugin: exec: "myscript.sh": executable file not found in $PATH

A closely related form appears when the file is found but lacks the execute bit:

E! [inputs.exec] Error in plugin: fork/exec /opt/scripts/myscript.sh: permission denied

Telegraf keeps collecting from other inputs, but the exec command produces no metrics until the path and permissions are corrected.

Symptoms

• Metrics from the custom exec command are entirely absent while other inputs report normally.
• journalctl -u telegraf repeats executable file not found in $PATH every collection interval.
• The command runs fine in your interactive shell but fails under the telegraf service user.
• The error appeared after moving Telegraf into a container that does not include the script or its interpreter.
• Switching the config from a bare command name to an absolute path makes the error disappear.

Common Root Causes

• Command referenced by bare name — commands = ["myscript.sh"] relies on PATH, but the systemd service starts with a minimal PATH that does not include the script’s directory.
• Script not executable — the file exists but is missing the execute bit, so lookup or fork fails.
• Service PATH differs from your shell — your login shell sources ~/.bashrc//etc/profile; the telegraf systemd unit does not, so /usr/local/bin or custom dirs are absent.
• Interpreter missing — the shebang points at /usr/bin/python3 or /bin/bash that is not installed in a slim container image.
• Script absent in the container — the Telegraf image was built without copying the script or mounting the host directory.
• Wrong working directory assumption — the script is referenced relatively and Telegraf’s cwd is not where you expect.
• Ownership/SELinux — the telegraf user cannot read/traverse the directory to reach the file.

Diagnostic Workflow

First confirm exactly what the service user sees, because your interactive PATH is usually richer than the daemon’s:

# What PATH does the running service actually have?
sudo systemctl show telegraf -p Environment
cat /proc/$(pgrep -x telegraf)/environ | tr '\0' '\n' | grep '^PATH='

# Can the service user find and run the script?
sudo -u telegraf which myscript.sh
sudo -u telegraf test -x /opt/scripts/myscript.sh && echo "executable" || echo "NOT executable"

Make the script executable and reference it by absolute path — this removes all PATH ambiguity:

sudo chmod +x /opt/scripts/myscript.sh
sudo chown telegraf:telegraf /opt/scripts/myscript.sh

Use an absolute path in the config and pin the expected data format:

[[inputs.exec]]
  commands = ["/opt/scripts/myscript.sh"]
  timeout = "5s"
  data_format = "influx"
  # If you must run an interpreted script, call the interpreter explicitly:
  # commands = ["/usr/bin/python3 /opt/scripts/collector.py"]

Run only the exec input with debug to confirm the command is found and emits parseable lines:

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

If you must keep a bare command name, extend the service PATH with a drop-in override instead of editing the packaged unit:

sudo systemctl edit telegraf

[Service]
Environment=PATH=/usr/local/bin:/usr/bin:/bin:/opt/scripts

sudo systemctl daemon-reload && sudo systemctl restart telegraf

For containerized Telegraf, bake the script and its interpreter into the image or bind-mount the directory, and verify from inside the container:

docker exec -it telegraf sh -c 'command -v /opt/scripts/myscript.sh; ls -l /opt/scripts/myscript.sh'

Example Root Cause Analysis

A team added a disk-inventory exec command that worked perfectly when they ran telegraf --test from their SSH session, so they shipped it. In production the metric never appeared and the log showed exec: "inventory.sh": executable file not found in $PATH. The difference: their interactive shell had /usr/local/bin on PATH (added by /etc/profile.d), but the systemd unit launched Telegraf with only /usr/bin:/bin, and inventory.sh lived in /usr/local/bin.

Dumping /proc/<pid>/environ for the running daemon confirmed the stripped-down PATH. Rather than patch PATH, they changed the config to the absolute path commands = ["/usr/local/bin/inventory.sh"] and re-ran the plugin under --test, which immediately produced metrics. The lesson: telegraf --test inherits your shell’s rich environment, but the systemd service does not — always reference exec commands by absolute path and validate as the telegraf user.

Prevention Best Practices

• Always use absolute paths in commands = [...]; never rely on the daemon’s PATH matching your shell’s.
• Set the execute bit and correct ownership (chmod +x, chown telegraf) as part of deployment, not manually.
• For interpreted scripts, invoke the interpreter explicitly (/usr/bin/python3 script.py) so a missing shebang target fails loudly.
• Validate custom commands with sudo -u telegraf and telegraf --test --input-filter exec, not just your interactive shell.
• In containers, copy the script and its runtime into the image (or bind-mount) and test with docker exec.
• Keep exec timeout shorter than the plugin interval so a hung script cannot stall collection.

Quick Command Reference

# See the service's real PATH and environment
sudo systemctl show telegraf -p Environment
cat /proc/$(pgrep -x telegraf)/environ | tr '\0' '\n' | grep '^PATH='

# Test as the service user
sudo -u telegraf test -x /opt/scripts/myscript.sh && echo OK
sudo -u telegraf /opt/scripts/myscript.sh

# Make executable and fix ownership
sudo chmod +x /opt/scripts/myscript.sh && sudo chown telegraf:telegraf /opt/scripts/myscript.sh

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

Related Guides

• Telegraf inputs.exec exit status 1
• Telegraf invalid configuration
• Telegraf input took longer to collect

More fixes in the Telegraf guides.

Conclusion

[inputs.exec] exec: "myscript.sh": executable file not found in $PATH means Telegraf’s minimal service environment could not locate the command — almost always because it was referenced by bare name, is missing the execute bit, or is absent from the container. Reference the command by absolute path, chmod +x it, and validate as the telegraf user with telegraf --test --input-filter exec. When you truly need a bare name, extend PATH via a systemd drop-in, and your exec metrics will collect reliably.