Bugs with iscsi-initiator-utils*-6.2.0.878-5

This is a quick post for anyone experiencing iSCSI (Internet Small Computer Systems Interface) target login issues on Linux 8. Symptoms include:

1. Upon machine start, iSCSI node target logon does not succeed automatically during the boot process. (This was first detected on a database server when the required database multipath devices were not present, preventing the database from starting.)

2. After other services start, a manual logon using “iscsiadm -m node -l all” is successful. This allows database services to restart. However, the manual iSCSI logon shouldn’t be required upon boot.

3. Console displays errors such as (repeatedly):

Jun  7 15:41:48 servername iscsid[1482]: iscsid: re-opening session -1 (reopen_cnt 0)
Jun  7 15:41:48 servername iscsid[1482]: iscsid: re-opening session -1 (reopen_cnt 0)
Jun  7 15:41:48 servername iscsid[1482]: iscsid: re-opening session -1 (reopen_cnt 0)
Jun  7 15:41:48 servername iscsid[1482]: iscsid: re-opening session -1 (reopen_cnt 0)

4. The Linux messages file (/var/log/messages) displays similar errors repeatedly:

Jun  7 15:54:21 servername iscsid[1469]: iscsid: re-opening session -1 (reopen_cnt 0)
Jun  7 15:54:21 servername iscsid[1469]: iscsid: expecting event 18, got 103, handling...
Jun  7 15:54:21 servername iscsid[1469]: iscsid: Received iferror -22: Invalid argument.
Jun  7 15:54:21 servername iscsid[1469]: iscsid: can't stop connection -1:0 (101)

Rediscovering iSCSI targets, checking /etc/multipath.conf, and associated udev rules are of no help.

The solution is to upgrade iscsi-initiator-utils and iscsi-initiator-utils-iscsiuio to a more recent version.

In my particular case, the OS starting point came from a major public cloud provider, had been provisioned with iscsi-initiator-utils*-6.2.0.878-5 (circa May 2021) and was not configured for internet access for automatic YUM (Yellowdog Updater, Modified) updates.

I resolved all issues by manually upgrading these RPMs to iscsi-initiator-utils*-6.2.1.2-1.

I double-checked that the RPM version was indeed the issue—as opposed to the iSCSI configuration being initially corrupted (i.e. that the version change resolved the issues, not the reinstall)—by manually downgrading back to the original version. The problem recurred after downgrading the RPM version, and was subsequently resolved after upgrading again.

I hope this was helpful. If you have questions or thoughts, please leave them in the comments.