Tumbleweed - iSCSI Initiator Yast Discovery/Connection Locks Up - stack smashing detected

I just installed the latest Tumbleweed (20191027) and yast is locking up while configuring a new connection (Network Services -> iSCSI Initiator -> Discovered Targets -> Connect). I am able to discover the targets and then after I specify the connection information (startup - automatic, authentication by targets) and and hit next (F10) Yast locks up. In the log files I can see a bunch of error messages from the iscisd service (detailed a little bit later).

The iSCSI target is on a QNAP NAS on my local LAN (and I have an OpenSuse Leap instance connected to another target on the same NAS).

I have tried this both on a clean install and in a virtual machine.

Via journalctrl I see the following messages:
Oct 30 10:38:54 tumbleweed-vm systemd[1]: Listening on Open-iSCSI iscsid Socket.
Oct 30 10:41:53 tumbleweed-vm iscsid[1146]: *** stack smashing detected ***: <unknown> terminated
Oct 30 10:41:53 tumbleweed-vm systemd[1]: iscsid.service: Main process exited, code=dumped, status=6/ABRT
Oct 30 10:41:53 tumbleweed-vm systemd[1]: iscsid.service: Failed with result ‘core-dump’.
Oct 30 10:41:53 tumbleweed-vm systemd[1]: iscsid.service: Service RestartSec=100ms expired, scheduling restart.
Oct 30 10:41:53 tumbleweed-vm systemd[1]: iscsid.service: Scheduled restart job, restart counter is at 1.
Oct 30 10:41:53 tumbleweed-vm iscsid[2613]: iscsid: Could not read data from db. Using default and currently negotiated values
Oct 30 10:41:53 tumbleweed-vm iscsid[2613]: iscsid: Invalid iscsi.FirstBurstLength of 0. Must be within 512 and 16777215. Setting to 262144
Oct 30 10:41:53 tumbleweed-vm iscsid[2613]: iscsid: Invalid iscsi.MaxBurstLength of 0. Must be within 512 and 16777215. Setting to 16776192
Oct 30 10:41:55 tumbleweed-vm iscsid[2613]: *** stack smashing detected ***: <unknown> terminated
(and this repeats over and over again)

Afterwards the service is in a failed state:
sudo systemctl status iscsid
iscsid.service - Open-iSCSI
Loaded: loaded (/usr/lib/systemd/system/iscsid.service; disabled; vendor preset: disabled)
Active: failed (Result: core-dump) since Wed 2019-10-30 11:07:06 EDT; 39s ago
Docs: man:iscsid(8)
man:iscsiuio(8)
man:iscsiadm(8)
Process: 6180 ExecStart=/sbin/iscsid -f (code=dumped, signal=ABRT)
Main PID: 6180 (code=dumped, signal=ABRT)
Status: “Syncing existing session(s)”

Oct 30 11:07:06 tumbleweed-vm systemd[1]: iscsid.service: Service RestartSec=100ms expired, scheduling restart.
Oct 30 11:07:06 tumbleweed-vm systemd[1]: iscsid.service: Scheduled restart job, restart counter is at 665.
Oct 30 11:07:06 tumbleweed-vm systemd[1]: Stopped Open-iSCSI.
Oct 30 11:07:06 tumbleweed-vm systemd[1]: iscsid.service: Start request repeated too quickly.
Oct 30 11:07:06 tumbleweed-vm systemd[1]: iscsid.service: Failed with result ‘core-dump’.
Oct 30 11:07:06 tumbleweed-vm systemd[1]: Failed to start Open-iSCSI.

I am then unable to start the iscsid service:> sudo systemctl start iscsid
Job for iscsid.service failed because a fatal signal was delivered causing the control process to dump core.
See “systemctl status iscsid.service” and “journalctl -xe” for details.

I had a previous version of Tumbleweed that was connected to this target and ran into this problem after reinstalling Tumbleweed the other day.

Any help would be appreciated.

Regards, Jeff

I’d suggest first verifying that your iscsi target is also running on system(s) that are fully updated and perhaps even running a version that is close to what you’re running in Tumbleweed.
I also don’t personally track what versions are running in Tumbleweed, since you’re already testing in a virtual machine, I’d recommend you also test in a LEAP machine.

You should submit a bug with your detailed findings to https://bugzilla.opensuse.org

The error suggests a coding error and not something a User would be expected to be able to address.

TSU

As an update to this issue - shortly, after posting this issue I submitted a bug (https://bugzilla.opensuse.org/show_bug.cgi?id=1155510). This ended up being an issue with iscisd: “new Authentication methods were added to the two that already existed, but one stack array, value_list in acl_init(), needed to be changed from [2] to [4], but was just changed to [3]”.

The iscsid changes were provided to me via an RPM which I tested and verified.

  • Jeff