From Fedora Project Wiki


This server provides ELF or DWARF debugging information, plus associated source code, covering all packages and architectures of recent versions of Fedora. It works by periodically indexing all relevant RPMs from Koji, and extracting any needed file on the fly. Debugger-type tools automatically request files one by one. After being downloaded, each file is stored in a cache under your home directory, where the tools can immediately use it.


On Fedora 32 or later, set an environment variable.


On Fedora 35 (rawhide) or later, this environment variable is automatically set via /etc/profile.d/debuginfod.* files.

If you operate your own debuginfod server for local projects, add its URL to $DEBUGINFOD_URLS (space-separated). If you'd like to see progress diagnostics during downloads, set:


If you want to see exactly which network requests are being made and which cached files are used you can set $DEBUGINFOD_VERBOSE (warning: very verbose):


If you want to limit download times and/or sizes, and are running elfutils version 0.186+, you can set these variables:

% export DEBUGINFOD_MAXTIME=10       # seconds
% export DEBUGINFOD_MAXSIZE=10000000 # bytes

Then, enjoy using gdb, stap, perf, eu-stack, and many other debugging-related tools without the interruption of % sudo yum debuginfo-install XYZZY.


If you wish to completely opt out of this service, clear $DEBUGINFOD_URLS. You can do this in your .bashrc file, depending on shell.


You may also disable it exclusively on GDB by adding the following command on your .gdbinit, or using it before starting your debug session:

set debuginfod enabled off

If you have a local debuginfod cache that you'd like to use, but don't want to attempt any upstream debuginfod queries, set $DEBUGINFOD_URLS to something non-empty but ineffective, such as /dev/null.

Clients automatically clean the cache of files not accessed in a while. You may also remove the debuginfod cache directory $HOME/.cache/debuginfod_client at any time.


While we intend to operate the fedora debuginfod server in a secure manner, some concerns naturally arise.


The fedora debuginfod server extracts files verbatim from koji-built RPMs, usually signed RPMs. However, since there exist no per-file signature facilities in effect, debuginfod cannot really assure the clients that the files are correct. (RPM signatures operate at the RPM package level, not at the file level.) Crafted or modified debuginfo files could in theory lead consumer tools to perform unintended or dangerous operations.

On the other hand, integrity in transit is protected by HTTPS (TLS). Integrity of the files at rest is improved by conservative file permissions to prevent accidental modification. We constantly monitor and update the server itself, so that we can reduce the risk of its exploitation.


Whenever a debuginfod client tool needs information it cannot find locally, it sends an HTTPS request containing:

  • inherently, the client machine's IP address
  • the hexadecimal buildid of the binary it is interested in
  • if requesting a source file (usually if the debuginfo has already been found), then that source file's name
  • a User-Agent: string identifying its version of fedora and elfutils, and the architecture name

This could disclose the existence of debugging activity to the servers. It is stored temporarily in the general logs in fedora infrastructure. These logs are not made public.

Note that once debuginfo information is cached locally, or if installed debuginfo is found, no HTTPS requests are made at all.

See also

See Also

For more information see elfutils status page and Changes/DebuginfodByDefault. What made all this possible: Releases/FeatureBuildId.