[BUG] JMXFetch getDSDStatus is flawed

[hvtuananh]

Agent version

7.72.1

Bug Report

#32919 by @tobz introduced a new way of detecting whether DogStatsD Server is running via UDP or UDS, but it's flawed:

https://github.com/DataDog/datadog-agent/blob/main/pkg/jmxfetch/jmxfetch.go#L531-L536

udsEnabled := pkgconfigsetup.Datadog().GetString("dogstatsd_socket") != ""
udpEnabled := pkgconfigsetup.Datadog().GetInt("dogstatsd_port") != 0

if dsdEnabled && udsEnabled {
	return DSDStatusRunningUDSDatagram
}

This code only checks if the dogstatsd_socket config is set in the agent config but it does not check if UDS is actually running. If Datadog agent is running on an environment where the Unix account does not have permission to write to the path specified in dogstatsd_socket (e.g. a daemonset in Kubernetes), JMXFetch will still assume UDS is running and send metrics to the non-existent socket and fail.

2025-12-02T16:47:15Z | JMX | ERROR | StatsD-Sender-pool-3-thread-1 | LoggingErrorHandler | statsd client error:
java.io.IOException: No such file or directory
        at jnr.unixsocket.UnixDatagramChannel.send(UnixDatagramChannel.java:176)
        at com.timgroup.statsd.StatsDSender$2.run(StatsDSender.java:103)
        at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
        at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
        at java.base/java.lang.Thread.run(Thread.java:829)

Reproduction Steps

No response

Agent configuration

Default Configuration

Operating System

Debian 6.12.47 x86_64 GNU/Linux

Other environment details

No response

[tobz]

@hvtuananh 👋🏻 Thanks for reporting this.

I agree that the logic is suboptimal, and it would be best if we were checking each possible transport before selecting it as the one to use for JMXFetch.

Out of curiosity, what does your deployment/installation method look like where you encountered this issue? Bare metal, Kubernetes? Official Datadog Agent installer/container images or something custom? It would definitely be concerning if a bog-standard Agent deployment/installation had permissions issues with its default run directory, which is something that should be handled by the installation scripts or taken care by virtue of the container spec.

[hvtuananh]

@tobz Thanks for your response, and apologies for my delayed reply—I'm traveling throughout December.

We encountered this issue while deploying the agent as a daemonset in Kubernetes. We did not explicitly mount /var/run/datadog as a writable path in our deployment configuration.