Strange ElasticAgent config path bug

Elastic Stack Elastic Agent
1

Hi community,

I observed a strang bug with the fleet managed elasticagent install on one of my servers. The agent would not start and would always spit out the error below. Note that the agent had been running for over 2 months at this point. The issue occured after a recent server reboot.

Error: could not read configuration file /etc/elastic-agent/elastic-agent.yml: open /etc/elastic-agent/elastic-agent.yml: no such file or directory

I don’t understand why or how it refers to the /etc/elastic-agent as the config directory. There was a empty directory on the system /etc/elastic-agent and removing that one made no difference. So I had to make some changes to the systemd unit reference below to fix the error.

To fix the issue I had to manually force add the config path as an argument

ExecStart = /usr/bin/elastic-agent --path.config /opt/Elastic/Agent

My suggestion, can the agent always append the config path as an argument when installing from the package?

Version info:
elastic-agent: Binary: 8.17.5 (build: 259c4b95efcf436a2e9a6c06bca4316fc7e61a9d at 2025-04-09 11:43:56 +0000 UTC)

OS: Ubuntu 22.04.5 LTS

systemd unit file for reference

[Unit]
Description               = Elastic Agent is a unified agent to observe, monitor and protect your system.
ConditionFileIsExecutable = /usr/bin/elastic-agent

[Service]
StartLimitInterval = 5
StartLimitBurst    = 10
ExecStart          = /usr/bin/elastic-agent
WorkingDirectory   = /opt/Elastic/Agent
Restart            = always
RestartSec         = 120
EnvironmentFile    = -/etc/sysconfig/elastic-agent
KillMode           = process

[Install]
WantedBy = multi-user.target
2

There are default settings. For specific cases, you have to use:
-c <string>
The configuration file to use. If not specified, Elastic Agent uses {path.config}/elastic-agent.yml.
--path.config <string>
The directory where Elastic Agent looks for its configuration file. The default varies by platform.

3

Hi @rios, thanks for the reply. What’s strange is that the agent functions properly on other servers with the same OS and installation method via DEB-package. But somehow on this specific server this issue occurred after 2 months of runtime after a reboot.