Red Hat Training

A Red Hat training course is available for Red Hat Ceph Storage

Chapter 7. Contacting Red Hat Support Service

If the information in this guide did not help you to solve the problem, this chapter explains how you contact the Red Hat Support Service.

7.1. Providing Information to Red Hat Support Engineers

If you are unable to fix problems related to Red Hat Ceph Storage by yourself, contact the Red Hat Support Service and provide sufficient amount of information that helps the support engineers to faster troubleshoot the problem you encounter.

Procedure: Providing Information to Red Hat Support Engineers

  1. Open a support ticket on the Red Hat Customer Portal.
  2. Ideally, attach an sosreport to the ticket. See the What is a sosreport and how to create one in Red Hat Enterprise Linux 4.6 and later? solution for details.
  3. If the Ceph daemons failed with a segmentation fault, consider generating a human-readable core dump file. See Section 7.2, “Generating Readable Core Dump Files” for details.

7.2. Generating Readable Core Dump Files

When a Ceph daemon terminates unexpectedly with a segmentation fault, gather the information about its failure and provide it to the Red Hat Support Engineers.

Such information speeds up the initial investigation. Also, the Support Engineers can compare the information from the core dump files with Red Hat Ceph Storage known issues.

Before You Start

  1. Install the ceph-debuginfo package if it is not installed already.

    1. Enable the repository containing the ceph-debuginfo package:

      subscription-manager repos --enable=rhel-7-server-rhceph-2-<daemon>-debug-rpms

      Replace <daemon> with osd or mon depending on the type of the node.

    2. Install the ceph-debuginfo package:

      # yum install ceph-debuginfo
  2. Ensure that the gdb package is installed and if it is not, install it:

    # yum install gdb

Procedure: Generating Readable Core Dump Files

  1. Enable generating core dump files for Ceph.

    1. Set the proper ulimits for the core dump files by adding the following parameter to the /etc/systemd/system.conf file:

      DefaultLimitCORE=infinity
    2. Comment out the PrivateTmp=true parameter in the Ceph daemon service file, by default located at /lib/systemd/system/<cluster-name>-<daemon>@.service:

      # PrivateTmp=true
    3. Set the suid_dumpable flag to 2 to allow the Ceph daemons to generate dump core files:

      # sysctl fs.suid_dumpable=2
    4. Adjust the core dump files location:

      # sysctl kernel.core_pattern=/tmp/core
    5. Reload the systemd service for the changes to take effect:

      # systemctl daemon-reload
    6. Restart the Ceph daemon for the changes to take effect:

      systemctl restart ceph-<daemon>@<ID>

      Specify the daemon type (osd or mon) and its ID (numbers for OSDs, or short host names for Monitors) for example:

      # systemctl restart ceph-osd@1
  2. Reproduce the failure, for example try to start the daemon again.
  3. Use the GNU Debugger (GDB) to generate a readable backtrace from an application core dump file:

    gdb /usr/bin/ceph-<daemon> /tmp/core.<PID>

    Specify the daemon type and the PID of the failed process, for example:

    $ gdb /usr/bin/ceph-osd /tmp/core.123456
  4. In the GDB command prompt apply the backtrace command to all threads of the process by entering thr a a bt:

    (gdb) thr a a bt
  5. Copy and paste the output from the previous command into a support ticket.

See Also