Check and Run iscsid Without Touching Live Storage

iscsid is the quiet control-path daemon behind Open-iSCSI, and a careless restart of it can leave a target logged in when you meant to just look. This walks you through identifying the installed daemon, checking its inputs, and starting it in a way you can undo. The examples use iscsid 2.1.9 from Ubuntu package open-iscsi 2.1.9-3ubuntu5.4. Allow about fifteen minutes.

1. Check the installed daemon

Run these read-only commands first, so you know which binary you are testing and which version supplies the behaviour described here:

$ command -v iscsid
/usr/sbin/iscsid
$ dpkg-query -W -f='${Package} ${Version}\n' open-iscsi
open-iscsi 2.1.9-3ubuntu5.4
$ iscsid --version
iscsid version 2.1.9

The installed manual describes iscsid as the Open-iSCSI control-path daemon. It is not the command that discovers targets or requests a login; those jobs belong to iscsiadm, which is outside this article.

2. Inspect the configuration inputs

By default, iscsid reads /etc/iscsi/iscsid.conf and /etc/iscsi/initiatorname.iscsi. The persistent node database normally lives under /etc/iscsi/nodes. Look at the paths and permissions without editing anything:

$ ls -ld /etc/iscsi /etc/iscsi/nodes
$ ls -l /etc/iscsi/iscsid.conf /etc/iscsi/initiatorname.iscsi
$ sed -n '1,80p' /etc/iscsi/initiatorname.iscsi
InitiatorName=iqn.2004-10.org.example:host-1234

• Your initiator name is host-specific. Do not paste the output above into a real file.
• The initiator file usually needs restrictive permissions. It identifies the host to storage targets.
• Never publish CHAP passwords from iscsid.conf. Keep them out of tickets, shell history and articles.

On a freshly installed machine, /etc/iscsi/nodes may not exist yet. That is not by itself a daemon failure, it just means no persistent node record has been created. A configured system can still contain node records, so check before assuming either state.

3. Read the effective service state

Use systemd's read-only status queries before starting anything:

$ systemctl is-enabled iscsid.service
disabled
$ systemctl is-active iscsid.service
inactive
$ systemctl status iscsid.service --no-pager

These results come from the machine used for this guide. Your host may report enabled and active, or use a socket-activated arrangement instead. Disabled means the unit will not start at boot; inactive means it is not running now. Neither result tells you whether a target exists or whether a login would succeed.

$ pgrep -a iscsid || true
$ systemctl status iscsid.socket --no-pager

4. Choose a controlled launch mode

For normal operation, let the distribution's service manager start the daemon. This needs elevated privileges and changes running system state:

$ sudo systemctl start iscsid.service
$ systemctl is-active iscsid.service
active

Starting iscsid does not log in to a target by itself, but it does create a daemon and can let later iSCSI management commands act. On a production host, announce the change first and check the unit's logs after starting it:

$ sudo journalctl -u iscsid.service -n 50 --no-pager

To undo just this example, stop the service once nothing depends on it:

$ sudo systemctl stop iscsid.service

Do not stop it during active storage use merely to tidy up a test; confirm sessions and mounts with your storage procedure first. Stopping the daemon is not the same as logging out, and it is not a safe substitute for a planned storage removal.

5. Run it in the foreground for diagnosis

The --foreground option keeps iscsid attached to the terminal and implies --no-pid-file. Useful for a controlled diagnostic session, disruptive if another daemon instance is already running. Use a maintenance shell and never combine it with a systemd-managed instance:

$ sudo systemctl stop iscsid.service
$ sudo iscsid --foreground --debug 3

Debug levels 0 through 8 are documented. Start modest, at 3, and raise it only when needed, since diagnostic output can include connection and protocol details. Keep the terminal open while you watch the result, then press Ctrl-C to end the foreground process and restore the service if the host needs it:

$ sudo systemctl start iscsid.service
$ systemctl is-active iscsid.service
active

If the foreground command fails immediately, verify the configuration and initiator paths rather than guessing at flags. An alternative config file can be supplied with -c or --config, and an alternative initiator file with -i or --initiatorname. Use those only with files you have reviewed and permissioned for the test.

6. Avoid pid-file and privilege traps

• Pid file defaults to /run/iscsid.pid. --pid=PATH picks another location, --no-pid-file disables it; the two options conflict, and neither should point at a shared or world-writable directory.
• --uid and --gid change the daemon's user and group. Get this wrong and you can lock out the control socket, configuration, device interfaces or pid file. Reproduce the deployment's documented service account and verify permissions in a disposable environment first, rather than treating this as a casual hardening toggle.

Use the built-in help when checking a script or unit override:

$ iscsid --help
Usage: iscsid [OPTION]
Open-iSCSI initiator daemon.

Remember that --help and --version exit without starting the daemon, which makes them the safest first commands when comparing hosts.