This article will describe the content and structure of the sosreport output. The aim is to improve its usefullness through a better understanding of its contents.

🧰 What is sosreport?

sosreport is a powerful command-line utility available on Fedora, Red Hat Enterprise Linux (RHEL), CentOS, and other RHEL-based systems to collect a comprehensive snapshot of the system’s configuration, logs, services, and state. The primary use is for diagnosing issues, especially during support cases with Red Hat or other vendors.

When executed, sosreport runs a series of modular plugins that collect relevant data from various subsystems like networking, storage, SELinux, Docker, and more. The resulting report is packaged into a compressed tarball, which can be securely shared with support teams to expedite troubleshooting.

In essence, sosreport acts as a black box recorder for Linux — capturing everything from system logs and kernel messages to active configurations and command outputs — helping support engineers trace problems without needing direct access to the system.

🛠️ How to Generate a sosreport

To use sosreport on Fedora, RHEL, or CentOS, run the following command as root or with sudo:

sudo sosreport

This command collects system configuration, logs, and command outputs using various plugins. After a few minutes, it generates a compressed tarball in /var/tmp/ (or a similar location), typically named like:

sosreport-hostname-20250623-123456.tar.xz

You may be prompted to enter a case ID or other metadata, depending on your system configuration or support workflow.

The sosreport generated tarball contains a detailed snapshot of the system’s health and configuration. It has a well-organized structure which reflects the data collected from the myriad Linux subsystems.

Exploring sosreport output is challenging due to the sheer volume of logs, configuration files, and system command outputs it contains. However, understanding its layout is key for support engineers and sysadmins to quickly locate and interpret crucial diagnostic information.

📁 sosreport directory layout

When the tarball is unpacked, the directory structure typically resembles this:

.
├── ./boot
├── ./etc
├── ./lib -> usr/lib
├── ./opt
├── ./proc
├── ./run
├── ./sos_commands
├── ./sos_logs
├── ./sos_reports
├── ./sos_strings
├── ./sys
├── ./usr
├── ./var
└── ./EXTRAS

CORE Breakdown:

  • Most directories mimic a standard Linux root filesystem and primarily contain configuration files.
  • The directories that don’t appear in a regular root filesystem include:
    • sos_command
    • sos_logs
    • sos_reports
    • sos_strings
    • EXTRAS

🔍 Key directories in detail

🔊 sos_commands/

This contains output from commands executed by each plugin. Its structure is plugin-specific:

./sos_commands/
├── apparmor/
├── docker/
├── memory/
├── networkmanager/
├── process/
│ ├── lsof_M_-n_-l_-c
│ ├── pidstat_-p_ALL_-rudvwsRU_--human_-h
│ ├── ps_auxwwwm
│ └── pstree_-lp

Each file name matches the Linux command used, with all options. The contents are the actual command output, making the plugin behavior transparent.

📊 sos_reports/

This directory contains multiple formats that index and summarize the entire sosreport:

  • sos.json: A machine-readable index of all collected files and commands.
  • manifest.json: Describes how sosreport executed – timestamps, plugins used, obfuscation done, errors, etc.
  • HTML output for easy browsing via browser.

📃 sos_logs/

Contains logs from the execution of sosreport itself.

  • sos.log: Primary log file that highlights any errors or issues during data collection.

📰 sos_strings/

  • Contains journal logs for up to 30 days, extracted using journalctl
  • Can be quite large, especially on heavily used systems
  • Structured into subdirectories like logs/ or networkmanager/

🔒 EXTRAS/

This is not a default part of an sosreport. It is created by the sos_extras plugin and used to collect any custom user-defined files.

🚀 Why this layout matters

  • Speed: Logical grouping of directories help engineers drill down without manually parsing GigaBytes of log files.
  • Traceability: Knowing where each file came from and what command produced it enhances reproducibility.
  • Automation: Tools like soscleaner or sos-analyzer rely on this structure for automated diagnostics.

✅ Final thoughts

While sosreport is a powerful diagnostic tool, its effectiveness hinges on understanding its structure. With familiarity, engineers can isolate root causes of failures, uncover misconfigurations, and collaborate more efficiently with support teams. If you haven’t yet opened one up manually, try it — there’s a lot to learn from the insides!

This is my first Fedora Magazine article, dedicated to my wife Rupali Suraj Patil — my constant source of inspiration.