Read SCSI Drive Temperature with scsi_temperature

You will use scsi_temperature to ask one or more SCSI devices for their temperature log and see the decoded result from sg_logs. The command reads device logs; it does not configure cooling, change a threshold or write to the device.

The route

Jump straight to the step you need, or tick off Done means at the end.

Before you start
Checkpoint: confirm the interface
Read one device
Check permissions without changing anything
Read several devices
Common failure modes

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.

Before you start

Check that the command and package are installed.

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.

Checkpoint: confirm the interface

Read the built-in usage message before supplying 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.

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 contains 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 use the informational exceptions log page when the first page is unavailable. A device that has no usable temperature log is not made compatible by repeating the command or adding --verbose.

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 requires it. The command still performs a read, but root access increases the consequence of pointing at an unintended 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 intended device.

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; replace the path with the correct SCSI device.

Read several devices

Pass multiple known device paths when you want one run for 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 that 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 therefore 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 replace this wrapper with 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 read log data. If you accidentally used the wrong path, stop, record the error, and rerun only after identifying the intended device.

Done means

You confirmed that scsi_temperature comes from the installed sg3-utils package.
You used a verified SCSI device path, not a placeholder or an ordinary file.
You received and checked the decoded temperature output, or recorded that the device does not expose a usable temperature log.
You treated a multi-device exit status as incomplete evidence and checked each device's output.