Check SCSI Device Readiness Safely with scsi_ready

Before you trust a SCSI disk with real work, ask it a simple question with scsi_ready: are you actually there. This guide covers the scsi_ready script installed by sg3-utils 1.46-3ubuntu4. Its local manpage is labelled sg3_utils 1.36, so where the two disagree, trust the installed script and observed behaviour.

Allow about ten minutes. You need a shell, the sg3-utils package, and the correct device path. The command sends SCSI TEST UNIT READY, which is a status probe. It does not format, mount, eject or write to the device. You may need elevated privileges when the device node is not readable, but sudo is not automatically required.

1. Identify the device node

Start by finding the device you intend to check. Use a path supplied by your storage inventory, or list likely SCSI generic and block devices:

$ ls -l /dev/sg* /dev/sd* /dev/sr* 2>/dev/null

Replace /dev/sgX below with a real path. Do not guess from a changing device order if the check is part of an automated job. A SCSI disk, tape drive or DVD or BD player may respond to TEST UNIT READY, but a regular file, pipe or arbitrary block device is not a safe stand-in for testing this command.

Checkpoint: confirm the path exists and identifies the expected hardware before proceeding:

$ test -e /dev/sgX && ls -l /dev/sgX

2. Run a normal readiness check

Run scsi_ready with the device as its final argument. This ordinary invocation prints the underlying sg_turs command before the result:

$ scsi_ready /dev/sgX
sg_turs  /dev/sgX
    ready

A successful TEST UNIT READY produces ready. A device can respond successfully while still being unsuitable for a particular read or write, this check only answers the narrower question of whether it accepts the SCSI readiness command at all.

For several devices, give several paths. The script checks them in order:

$ scsi_ready /dev/sgX /dev/sgY

Each path goes to sg_turs in turn. It is a status query, so the example does not change media or filesystem state.

3. Use brief output for a human-facing check

Add --brief when the command line above is just noise and you only want one result line per device:

$ scsi_ready --brief /dev/sgX /dev/sgY
    ready
    device not ready

The local manpage describes the two result lines as ready and device not ready. A missing device or another serious error gets printed as an error instead. The option has the short form -b.

Use --verbose, or repeat -v, when you need more detail from sg_turs while investigating a result:

$ scsi_ready --verbose /dev/sgX

Do not build a parser around verbose text. It exists for investigation, not as a stable data format.

4. Check failures without changing the device

First separate a bad path, a permission problem and a genuine not-ready response. A nonexistent path is a useful, safe way to see the failure display:

$ scsi_ready /dev/does-not-exist
sg_turs  /dev/does-not-exist
    main: error opening file: /dev/does-not-exist: No such file or directory

For a real device, inspect its ownership and permissions before reaching for sudo. If policy allows it, retry the same read-only probe with elevation:

$ sudo scsi_ready /dev/sgX

If the elevated run succeeds, fix the access policy through the normal device-management mechanism rather than handing broad permissions to a monitoring service. If it still fails, check the kernel log and the device's transport separately. Do not treat an ioctl error from an unsuitable path as evidence that a disk is not ready.

5. Treat the exit status as a version-specific trap

The scsi_ready manpage says its status is 0 on success and otherwise is the status of the last sg_turs invocation. That is the contract a script would naturally rely on. Here is the catch: the installed 1.46 shell script does not explicitly exit with that status, and its loop can finish with status 0 even after sg_turs has failed. You can see it happen on this machine:

$ scsi_ready /dev/does-not-exist
sg_turs  /dev/does-not-exist
    main: error opening file: /dev/does-not-exist: No such file or directory
$ printf 'status=%s\n' "$?"
status=0

Do not use this wrapper's exit code alone as proof of readiness on this installed version. For automation, capture and inspect its output, or call sg_turs directly when you need its documented status values. The sg_turs manpage documents status 0 for success and status 2 for the SCSI not-ready sense key; other values mean other errors.

When you call sg_turs directly, keep its one-device scope and check its status immediately:

if sg_turs /dev/sgX; then
    printf '%s\n' 'device accepted TEST UNIT READY'
else
    status=$?
    printf 'sg_turs failed with status %s\n' "$status" >&2
    exit "$status"
fi

This direct form suits a service health check better, though it still depends on the device's permissions and transport. Record the status and diagnostic output together so a transient not-ready response is never confused with a missing device.

6. Confirm what the check did

After a manual run, repeat the command with --brief if you want a clean checkpoint:

$ scsi_ready --brief /dev/sgX

There is no configuration file to edit and no enable operation hidden behind this command. -h or --help prints usage, while -b and -v control presentation and diagnostics. A successful probe does not prove that a filesystem is mounted, that media is present, or that an application can complete its own workload on top of it.

Done means