Start SCSI Disks Safely with scsi_start

You will use scsi_start to send the SCSI START STOP UNIT command to one or more disks, then confirm that the command completed. 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 power, 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 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 touching 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 corresponding long forms shown above. A device argument 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 that you have already matched to the correct disk. For example, inspect the current block-device inventory without changing it:

$ 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 where USB, multipath or hot-plug storage is present. A stable identifier under /dev/disk/by-id/ can be easier to review, but it still must point to 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 remain 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 proceeds. 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 that 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 requested start command was accepted and completed according to the underlying utility.

4. Understand immediate mode

Without --wait, scsi_start performs each start in immediate mode. That lets the script move on before the device has finished spinning up. This can be useful for a small, deliberate batch, but it changes what a successful return means: it confirms that the request was sent, not necessarily 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 prevents the script from issuing all starts 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 as a performance suggestion.

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 include the system disk, a removable device or a path that appeared after a hot-plug event. If the command fails part way through, check which devices were 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 enough detail:

$ 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 using 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 requests a start. The inverse operation, 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.