Start SCSI Disks Safely with scsi_start

A parked disk will not respond to anything until you send the SCSI START STOP UNIT command, which is exactly what scsi_start wraps. Allow about ten minutes for a single known device, or longer if you need to identify a storage path first. Starting a disk changes its power state and can make it draw more current, so do this during a suitable maintenance window.

This guide describes the installed sg3-utils package, version 1.46-3ubuntu4, on this machine. The local scsi_start(8) page carries the older sg3_utils-1.36 header, so the command's own help output is the more useful check for the installed interface. The examples assume a Linux host with a SCSI disk at a path such as /dev/sdX.

1. Confirm the command and package

Check the executable and its usage before you touch a device. These are ordinary, read-only commands and normally do not need elevated privileges:

$ command -v scsi_start
/usr/bin/scsi_start
$ dpkg-query -W -f='${Package} ${Version}\n' sg3-utils
sg3-utils 1.46-3ubuntu4
$ scsi_start --help
Usage: scsi_start [-h] [-v] [-w] <device>+
  where:
    -h, --help        print usage message
    -v, --verbose     more verbose output
    -w, --wait        wait for each start to complete

The command requires at least one device. Its short options are -h, -v and -w, with the long forms shown above. A device argument here is not a regular data file: it identifies a block or SCSI generic device that can receive a storage command.

2. Identify the exact device

Use a device path you have already matched to the correct disk. Inspect the current block-device inventory without changing anything:

$ lsblk -o NAME,PATH,MODEL,SERIAL,TYPE,SIZE,MOUNTPOINTS
$ test -b /dev/sdX && echo 'block device exists'
block device exists

Replace /dev/sdX with the real path. Do not guess from the order of disks in lsblk, especially on a host with USB, multipath or hot-plug storage present. A stable identifier under /dev/disk/by-id/ is easier to review, but it still has to point at the intended disk.

Starting a disk is not a harmless probe. It may wake a sleeping drive, increase power draw, or change the behaviour of a device that another service expects to stay stopped. It does not mount a filesystem, and it does not make a disk safe to detach. If the device is managed by a storage platform, follow that platform's procedure instead of issuing a direct command.

3. Start one disk and wait for completion

Use --wait when you want each start operation to complete before the script moves on. Access to a device often requires root, so use sudo only if an unprivileged trial reports a permission error:

$ sudo scsi_start --wait /dev/sdX
$ printf 'exit status: %s\n' "$?"
exit status: 0

The script calls sg_start for the device. A zero exit status means the script completed successfully. The local manual says the script returns zero on success; otherwise it returns the status from the last sg_start invocation. With no error text and status zero, the start command was accepted and completed according to the underlying utility.

4. Understand immediate mode

Without --wait, scsi_start runs each start in immediate mode. That lets the script move on before the device has actually finished spinning up. Useful for a small, deliberate batch, but it changes what a successful return means: it confirms the request was sent, not that every disk is ready for normal I/O.

$ sudo scsi_start /dev/sdX
$ printf 'request status: %s\n' "$?"
request status: 0

For one disk, --wait is usually clearer. For several disks, it also stops the script issuing every start at once. The manual specifically warns that starting a large number of disks together without --wait can overload a power supply. Treat that warning as an operational limit, not a performance tip.

5. Start several disks in a controlled sequence

Pass multiple device paths in one invocation when they are all known and approved. With --wait, the script handles them one at a time:

$ sudo scsi_start --wait /dev/sdX /dev/sdY /dev/sdZ
$ printf 'batch status: %s\n' "$?"
batch status: 0

Keep the list explicit. Do not build it from an unreviewed wildcard such as /dev/sd*, that can pull in the system disk, a removable device or a path that only appeared after a hot-plug event. If the command fails part way through, check which devices already started before rerunning it. Because the exit status is that of the last sg_start call, a non-zero result identifies a failed final operation but does not by itself tell you whether an earlier device succeeded.

6. Use verbose output for a failed request

Add --verbose when the normal output does not give you enough to go on:

$ sudo scsi_start --verbose --wait /dev/sdX
$ printf 'exit status: %s\n' "$?"
exit status: 0

Exact diagnostic text depends on the device, transport and kernel. If the command reports that the path cannot be opened, check the path and permissions. If it reports a SCSI or transport error, inspect the relevant kernel messages and storage controller logs through your normal operations process. Do not repeatedly retry a device that is disappearing, returning hardware errors or belonging to an active failover system.

If you started the wrong disk, stop issuing commands and confirm its identity before doing anything else. scsi_start has no undo option because it only ever requests a start. The inverse, stopping or ejecting a unit, is a separate action and can interrupt I/O, so do not invent a recovery command from this guide. Restore service through the storage system's documented procedure if a mistake affected a managed disk.