Run and Check the Open-iSCSI iscsid Daemon Safely

You will identify the installed Open-iSCSI daemon, check its inputs without changing storage, and choose a safe way to run it. The examples use iscsid 2.1.9 from Ubuntu package open-iscsi 2.1.9-3ubuntu5.4. Allow about fifteen minutes for the checks. Connecting to a target, logging in, logging out and mounting a remote block device are separate storage operations and are not performed by this guide.

1. Check the installed daemon

Run these ordinary, read-only commands first. They confirm which binary is being tested 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 used to discover targets or request a login. Those management operations belong to iscsiadm, which is outside this article.

Checkpoint: if command -v finds nothing, stop here and install or repair the distribution's open-iscsi package through your normal change process. Do not copy a daemon binary from another host.

2. Inspect the daemon's configuration inputs

By default, iscsid reads /etc/iscsi/iscsid.conf and /etc/iscsi/initiatorname.iscsi. The persistent node database is normally under /etc/iscsi/nodes. Inspect the paths and permissions without editing them:

$ 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, so do not paste the output above into a real file. The initiator file commonly needs restrictive permissions because it identifies the host to storage targets. Never publish CHAP passwords from iscsid.conf or copy them into a ticket, shell history or article.

On a newly installed machine, /etc/iscsi/nodes may not exist. That is not by itself a daemon failure: it indicates that no persistent node record has been created yet. A configured system can contain node records, so inspect 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 are examples from the machine used for this guide. Your host may report enabled and active, or may use a socket-activated arrangement. Disabled means the unit is not configured to start at boot; inactive means it is not running now. Neither result says whether a target exists or whether a login would succeed.

Checkpoint: record whether another operator or service already owns the daemon. Do not start a second copy just because a manual command returned no useful output. Check the process and unit state first:

$ 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 requires elevated privileges and can change running system state:

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

Starting iscsid does not itself log in to a target, but it does create a daemon and can make later iSCSI management commands able to act. If this is a production host, announce the change and check the unit's logs after the start:

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

To undo only this example, stop the service when no iSCSI management operation or mounted remote filesystem 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. This is useful for a controlled diagnostic session, but it is service-disrupting if another daemon is already running. Use a maintenance shell and do not 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 with a modest level such as 3 and increase it only when needed, because diagnostic output can include connection and protocol details. Keep the terminal open while observing the result. Press Ctrl-C to end this foreground process, then 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 file can be supplied with -c or --config, and an alternative initiator file with -i or --initiatorname. Use those options only with files you have reviewed and permissioned for the test.

6. Avoid pid-file and privilege traps

By default, iscsid uses /run/iscsid.pid. --pid=PATH selects another pid file, while --no-pid-file disables it. The two options conflict. Do not point a pid-file option at an arbitrary shared or world-writable directory.

The --uid and --gid options select the user and group IDs for the daemon. Changing them can prevent access to the control socket, configuration, device interfaces or pid file. Do not use them as a casual hardening toggle. First reproduce the deployment's documented service account and verify the resulting permissions in a disposable environment.

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. They are the safest first commands when comparing hosts.