Avoid duplicate error output between Cobra and otelcol logging

[byehn]

Component(s)

otelcol

Describe the issue you're reporting

Currently, the cobra.Command constructed in otelcol does not set SilenceErrors to true. At the same time, command execution errors are handled in runInteractive, where they are logged at fatal level.

Given that errors are already logged explicitly through "log" package(with fatal level), it seems redundant for Cobra to also print errors directly to stderr. Based on this, I’d like to propose setting SilenceErrors: true on the cobra.Command to avoid duplicate error output.

Tip

_{React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.}

[axw]

As an example, here's the output when using a non-existent subcommand:

$ ./otelcorecol foo
Error: unknown command "foo" for "otelcorecol"
Run 'otelcorecol --help' for usage.
2025/12/18 11:27:58 collector server run finished with error: unknown command "foo" for "otelcorecol"

Based on this, I’d like to propose setting SilenceErrors: true on the cobra.Command to avoid duplicate error output.

If we do that, then the output looks like this:

$ ./otelcorecol foo
2025/12/18 11:34:25 collector server run finished with error: unknown command "foo" for "otelcorecol"

Alternatively we could remove the log.Fatal calls and instead call os.Exit(1), leaving Cobra to print the error message. That would look like this:

$ ./otelcorecol foo
Error: unknown command "foo" for "otelcorecol"
Run 'otelcorecol --help' for usage.

I think this is most user-friendly output of the three.

[Syedowais312]

Hey @axw @evan-bradley
I’ve opened a PR that removes log.Fatalf from the builder main.go.tmpl and instead exits with a non-zero status (os.Exit(1)), allowing Cobra to fully own CLI error output.
With this change, invalid commands (e.g. otelcorecol foo) no longer produce duplicate error messages, while preserving the existing exit code behavior.
Please let me know if you’d prefer a different approach or any adjustments to the current implementation.