inputs.execd: internal influx parser ignores config

[m-hau]

Relevant telegraf.conf

[[inputs.execd]]
  command = ["/usr/bin/echo", "my_series,my_tag_key=my_tag_value my_field=987i 12345"]
  signal = "none"

  data_format = "influx"
  influx_timestamp_precision = "1s"
  #influx_parser_type = "upstream"

Logs from Telegraf

# ./telegraf --config my_config.conf --debug --test
2026-07-24T15:35:02Z W! Strict environment variable handling is the new default starting with v1.38.0! If your configuration does not work with strict handling please explicitly add the --non-strict-env-handling flag to switch to the previous behavior!
2026-07-24T15:35:02Z I! Loading config: my_config.conf
2026-07-24T15:35:02Z I! Starting Telegraf 1.40.0-4c365e3d brought to you by InfluxData the makers of InfluxDB
2026-07-24T15:35:02Z I! Available plugins: 245 inputs, 9 aggregators, 35 processors, 26 parsers, 68 outputs, 8 secret stores
2026-07-24T15:35:02Z I! Loaded inputs: execd
2026-07-24T15:35:02Z I! Loaded aggregators:
2026-07-24T15:35:02Z I! Loaded processors:
2026-07-24T15:35:02Z I! Loaded secretstores:
2026-07-24T15:35:02Z W! Outputs are not used in testing mode!
2026-07-24T15:35:02Z I! Tags enabled: host=my_host
2026-07-24T15:35:02Z W! [agent] The default value of 'skip_processors_after_aggregators' will change to 'true' with Telegraf v1.40.0! If you need the current default behavior, please explicitly set the option to 'false'!
2026-07-24T15:35:02Z D! [agent] Initializing plugins
2026-07-24T15:35:02Z D! [agent] Starting service inputs
2026-07-24T15:35:02Z I! [inputs.execd] Starting process: /usr/bin/echo [my_series,my_tag_key=my_tag_value my_field=987i 12345]
2026-07-24T15:35:02Z D! [agent] Stopping service inputs
> my_series,host=my_host,my_tag_key=my_tag_value my_field=987i 12345
2026-07-24T15:35:02Z I! [inputs.execd] Process /usr/bin/echo shut down
2026-07-24T15:35:02Z D! [agent] Input channel closed
2026-07-24T15:35:02Z D! [agent] Stopped Successfully

System info

Official Telegraf 1.39.2 release deb and master branch build from source, Debian 13

Docker

No response

Steps to reproduce

1. Start Telegraf with the above config. Test-mode is easiest since it will run once and directly print the metrics.
2. Check the generated metric and the timestamp

Expected behavior

The command returns the second-resolution timestamp 12345, which the internal parser should interpret as seconds due to the influx_timestamp_precision = "1s" option, and convert it to the nanosecond-resolution equivalent 12345000000000 (add 9 zeros at the end) before passing it on.

Actual behavior

The returned second-resolution timestamp 12345 is passed on as-is as nanosecond-resolution, resulting in the metric having 12345 (nanoseconds) as timestamp.

Additional info

The example above uses the influx_timestamp_precision option as an example since it's basically the only option for the influx parsers, but the problem would probably be same for any other influx parser option.

In the execd input plugin there is a special-case in SetParser() for the internal influx parser, which makes it use a different cmdReadOutStream codepath than for all the other parsers. In that codepath the properly-configured parser passed in via SetParser() is ignored, and instead a new parser (with only default-configuration) is created via the NewStreamParser(). Contrary to the Telegraf configuration file, that parser will then expect/interpret timestamps as nanosecond-resolution, which is why no conversion is done.

Switching to the upstream parser (commented out in the config above), the execd input plugin will use the cmdReadOut codepath, which does use the properly-configured parser passed in via SetParser() and properly convert the second-resolution timestamp from the command.

I also don't understand why the internal influx parser gets handled specially here to use a (I suppose more efficient) streaming approach, rather than line-by-line handling like all the rest. The Influx Line Protocol is by its very name and nature line-based, so I can't imagine a streaming approach makes that much of a difference (although I don't have any hard numbers to back that up). It would be a totally different story for (mostly) multi-line-formats like JSON, but for all these the execd input plugin will only use the line-by-line approach.

I am aware that the upstream parser is the way forward, can be enabled/used today, and will become the default at some point. But it isn't the default yet, and at the very least I wanted to document this difference in behaviour. I will leave the judgement, whether this is worth fixing, to the maintainers.