Infinity reboot agent 9.4.3

[Times-Z]

Hello,

I have a strange issue with Elastic Agent version 9.4.3.

I am using the Docker container version, and the container keeps restarting in a loop with the following log:

agent container initialisation - effective capabilities
agent container initialisation - ambient capabilities
agent container initialisation - chown paths
{"log.level":"warn","@timestamp":"2026-07-09T07:08:38.170Z","log.logger":"tls","log.origin":{"function":"github.com/elastic/elastic-agent-libs/transport/tlscommon.(*TLSConfig).ToConfig","file.name":"tlscommon/tls_config.go","file.line":185},"message":"SSL/TLS verifications disabled.","ecs.version":"1.6.0"}
{"log.level":"warn","@timestamp":"2026-07-09T07:08:38.410Z","log.origin":{"function":"github.com/elastic/elastic-agent/internal/pkg/agent/application/upgrade/artifact.(*Config).Unpack","file.name":"artifact/config.go","file.line":186},"message":"agent.download.retry_sleep_init_duration must be > 0, got 0s; using default 30s","ecs.version":"1.6.0"}

The Fleet Server and the entire Elastic Stack are also running version 9.4.3.
This issue occurs with both an empty policy and policies that are already being used by other agents.
The problem does not occur with version 9.4.2 or any earlier version. I am able to reproduce it both locally and on servers in our infrastructure.

[cmacknz]

This sounds the same as #15419

[infra-vault-gh-plugin-prod]

Pinging @elastic/elastic-agent-control-plane (Team:Elastic-Agent-Control-Plane)

[cmacknz]

This one doesn't explicitly contain Warning: cannot chown agent paths without CAP_CHOWN or CAP_DAC_OVERRIDE capabilities so I'm not convinced it's exactly the same mechanism yet.

[Times-Z]

Hummm maybe, it's on an Azure VM that I discovered this behaviour
But yes I don't have any capabilities problem so far on my side, even in other servers

[swiatekm]

We've done some overdue dependency bumps in 9.4.3: e29c596 49e2002. Hard to say from the logs without reproducing, but there might be some unexpected interaction there. Might also be one of the container cmd changes. #15419 is on Azure Container Apps and from what I can see, you're running the container in WSL - is that right? There may be an underlying commonality in the platform causing this problem.

[Times-Z]

Indeed
I would take some time the next week to provide more informations if I can
But yes, your right. My local environment is windows based with wsl for work, and we have this strange behaviour on Azure VM
So maybe it's related, I would try on debian on prem's server if I have the same result with the policy currently working on 9.4.2 but not on 9.4.3
I'll keep you updated

[swiatekm]

I'd be surprised if it reproduced in any kind of plain Linux or container environment, we have a lot of testing for those. We do not test on WSL or proprietary container execution environments, so I can easily believe something broke quietly there.