Read SCSI Drive Temperature with scsi_temperature

Ask a SCSI drive how hot it is running with scsi_temperature before a slow thermal problem turns into a support ticket. The command reads device logs; it does not configure cooling, change a threshold or write to the device.

Allow about five minutes if the device path is known. Allow longer if you need to identify a disk first. You need the sg3-utils package and a SCSI device path such as /dev/sg2. Reading a log is normally harmless, but a device may still be in active service, so run this during ordinary monitoring rather than while changing storage topology.

1. Confirm the command and package

Check that the command and package are installed before you touch anything:

command -v scsi_temperature
dpkg-query -W sg3-utils

On the system used for this guide, the package is sg3-utils 1.46-3ubuntu4. The installed manual page carries an older sg3_utils-1.36 header, so use the command and local output as the authority for this machine. The wrapper delegates the actual request to sg_logs.

2. Read the usage message first

Check the built-in usage message before you supply a device:

scsi_temperature --help

You should see a usage line equivalent to:

Usage: scsi_temperature [-h] [-v] <device>+
  where:
    -h, --help           print usage message
    -v, --verbose        more verbose output

The command needs at least one device. Both short and long options are available: -h or --help, and -v or --verbose. There is no option in this wrapper for selecting a log page, setting a temperature limit or changing device state.

3. Read one device

Run the command against the SCSI generic path for the device you want to inspect:

scsi_temperature /dev/sg2

The wrapper prints the sg_logs invocation and then runs it. A successful response is decoded by sg_logs and carries temperature information when the device supplies a supported temperature log. Exact fields and units depend on the device and its firmware, so do not script against a made-up sample line. For more detail, add verbosity:

scsi_temperature --verbose /dev/sg2

The underlying utility checks the temperature log page first and can also fall back to the informational exceptions log page when the first is unavailable. A device with no usable temperature log is not made compatible by repeating the command or adding --verbose.

4. Check permissions without changing anything

If an ordinary invocation reports a permissions or pass-through error, retry the same read with elevated privileges:

sudo scsi_temperature /dev/sg2

Only use sudo when the error actually requires it. The command still performs a read, but root access raises the stakes if you point it at the wrong device. Confirm the path first with your host's storage inventory, and keep the placeholder /dev/sg2 out of a copied command until it names the real target.

For example, /dev/null is not a SCSI device. Running against it produces an inquiry or pass-through error, not a temperature reading. That is a useful sanity check for the failure path, but it is not a substitute for a real device:

scsi_temperature /dev/null

The installed command reports that the device does not respond to SCSI inquiry and returns a non-zero status. No recovery action is needed; just replace the path with the correct SCSI device.

5. Read several devices

Pass multiple known device paths when you want one run to cover several devices:

scsi_temperature /dev/sg2 /dev/sg3

The wrapper processes the arguments in order and prints an sg_logs command for each one. Watch the device name beside each result. A common distraction is assuming one successful reading proves every device worked.

There is also a scripting trap: the documented exit status is zero when the script succeeds, otherwise it is the status from the last sg_logs invocation. With several devices, an earlier failure can be hidden by a later success. If every device matters, inspect the output for each path and check them individually in automation.

Common failure modes

• Missing command. Install the distribution's sg3-utils package, then rerun the package check. Do not swap in an unrelated temperature tool without checking its device support.
• Permission denied or pass-through failure. Verify the device path, then try the same read with sudo if local policy permits it.
• No temperature log. Treat the device as unsupported for this query. Do not infer a safe temperature from an absent value.
• Unexpected output. Rerun with --verbose, record the device path and package version, and compare the result with the device documentation.

No undo command is required because scsi_temperature and its delegated sg_logs call only read log data. If you used the wrong path by accident, stop, record the error, and rerun only after identifying the intended device.