errors in services don't abort the Agent startup

[tpaschalis]

Right now, an error in services doesn't stop the Agent from starting up. This means that two agents can start on colliding ports, or with incorrectly setup TLS configs.

Since this was not the intent of the original RFC, and we haven't decided on grafana/agent#4411 to allow working with a partially-evaluated graph, I think this should be regarded as a bug.

[github-actions]

This issue has not had any activity in the past 30 days, so the needs-attention label has been added to it.
If the opened issue is a bug, check to see if a newer release fixed your issue. If it is no longer relevant, please feel free to close this issue.
The needs-attention label signals to maintainers that something has fallen through the cracks. No action is needed by you; your issue will be kept open and you do not have to respond to this comment. The label will be removed the next time this job runs if there is new activity.
Thank you for your contributions!

[rfratto]

Hi there 👋

On April 9, 2024, Grafana Labs announced Grafana Alloy, the spirital successor to Grafana Agent and the final form of Grafana Agent flow mode. As a result, Grafana Agent has been deprecated and will only be receiving bug and security fixes until its end-of-life around November 1, 2025.

To make things easier for maintainers, we're in the process of migrating all issues tagged variant/flow to the Grafana Alloy repository to have a single home for tracking issues. This issue is likely something we'll want to address in both Grafana Alloy and Grafana Agent, so just because it's being moved doesn't mean we won't address the issue in Grafana Agent :)

[rfratto]

Just to add onto this, you also don't get any log lines that the service failed; the Run method of the service returns an error but that error is never logged anywhere. Since that could be fixed without fixing the abort issue, should I create a separate issue for that? Or does it make sense to roll both of these up into the same bug?

Edit: I created #694 anyway just because the lack of any indication that the HTTP service failed is annoying, and it'll be faster to fix the logging issue first just to get some indication that there's something wrong while we wait for a fix for this issue.