elastic-agent status: elastic-agent-control.sock: connect: no such file or directory

[mtojek]

Hi,

I tried to integrate with elastic-agent status, but it always fail with:

bash-4.2$ ./elastic-agent status
Error: failed to communicate with Elastic Agent daemon: rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing dial unix /usr/share/elastic-agent/data/tmp/elastic-agent-control.sock: connect: no such file or directory"

More data:

bash-4.2$ find . | egrep ".sock$"
./state/data/tmp/elastic-agent.sock
./state/data/tmp/default/metricbeat/metricbeat.sock
./state/data/tmp/default/filebeat/filebeat.sock
./state/data/tmp/elastic-agent-control.sock

Missing state?

[elasticmachine]

Pinging @elastic/agent (Team:Agent)

[blakerouse]

Ah I forgot that the container is used that STATE_PATH to adjust its path, ensuring that state is maintained across restarts of the container.

Hmm, need to figure out how to make this command work in the container.

[mtojek]

Do you think it's possible to include some integration tests with real agent's Docker container? Many of such issues slips through standard unit tests and I'm afraid that end-to-end testing is too late. /cc @ruflin

[blakerouse]

Being that the docker container requires actually packages of at least filebeat and metricbeat (good testing would require fleet-server which comes from a different repository) it would be very difficult to add and would really be doing exactly what the e2e testing suite is doing with the built packages.

We need the testing of e2e to be complete it is already a requirement for passing with /package comments.

[mtojek]

I see, let me share my feedback - I have feeling (maybe wrong?) that end-to-end tests are the first candidate to be ignored if there are other, potentially flaky, problems with PRs in Beats.

That's why I'm wondering if any testing part can be improved to fail fast in case of inconsistencies or errors. In general end-to-end tests take much time to run, so it would be better to target some quick smoke tests.

[mtojek]

Hi, it would be nice to give this issue higher priority. It seems to be the last piece of the container lifecycle.

[ruflin]

I looked a bit into the code around this. It seems to be related to the STATE_PATH that is set differently when run with container. I can think of two solutions:

• Persist state path and use it for all commands: I wonder if we already do this? Do we persist the state path somewhere so when any elastic-agent command is run afterwards, it can also use it.
• Support passing in STATE_PATH for elastic-agent status, basically have something similar to setPaths* that we have in container command

My preference is on option one, as it would make sure other commands could also use it directly without having to pass in STATE_PATH and potentially other vars every time.

[mtojek]

A lousy thought to what @ruflin wrote: I believe the default setup should work out of the box without additional flags like STATE_PATH. This looks to me as leaking internals that a standard user wouldn't need to know about.

[ruflin]

One more reason a prefer option 1. STATE_PATH is set internally by the container commands and should afterwards automatically be respected by other commands.

[blakerouse]

Yes this should work out of the box, setting STATE_PATH should not be required.