During upgrades of open-iscsi on my environment it fails to run
postinst with success.  I got the following messages:

Setting up open-iscsi (2.1.3-5) ...
open-iscsi postinst: since the check in preinst some iSCSI sessions have
                     failed. -> will wait 30s for automatic recovery
open-iscsi postinst: some sessions are still in failed state -> iscsid
                     will be restarted regardless, since that may
                     actually help with the session recovery.
dpkg: error processing package open-iscsi (--configure):
 installed open-iscsi package post-installation script subprocess returned error exit status 1


I have tried to change the postinst to wait for more time, for example
120s and it worked, after 40 seconds of wait.

Kind regards
Jose M Calhariz

Hello Jose,

Good to hear from you. I recollect having met you, in person, at
Debconf Heidelberg or Debconf Capetown. I hope you are doing good. :-)

Hmmm. Usually, the sessions should recover within a couple of seconds.
IIRC, the check is every 5 seconds.


Did you change/tweak any of the default timeout values ?

Hi


Yes, I am fine and you?  I was in both DebConfs but I remember meeting
you in Capetown.

Most probably, it is not me that usually setup the iSCSI connections.
What values do you want me to look into it and where?


Kind regards
Jose M Calhariz

There will be per target database created under that folder. And those
will have all the finer session and replacement timeouts defined. They
are usually generated/updated through the `iscsiadm` utility during
discovery.

PS: That db may also include CHAP secrets, if you set any.

OK,

I will send to you the iSCSI setup without secrets and we will put in
the bug report the relevant info.

Kind regards
Jose M Calhariz

Hi,

I was expecting to be easy to collect the info in one or 2 files, but
I am wrong.  I have 3 targets with multipath for 2 of them and I am
not certain what is active.  I have multipath active, I am certain of
that, because of the device I am mouting:
/dev/mapper/mpath-XXXXX-part1

So I am expecting you need all files inside /etc/iscsi and some
run-time info?

Kind regards
Jose M Calhariz

I am asking this information just for the sake of this task, to
ascertain why it failed in the first 30 seconds.

Since this worked for you, later, when you increased the timeout to 120
seconds; there's not much to do I suppose. But yes, from this bug
report's sake, having that information clarified will be good.

Given this bug report, I validated the upgrade on my local box. It is a
fairly complex configuration pulling in all bits: iSCSI, Multipath,
Root on Multipath (iSCSI) etc.

I can confirm that the upgrade went proper without any glitch. Relevant
snippets below:

Preparing to unpack .../20-libisns0_0.100-3_amd64.deb ...
Unpacking libisns0:amd64 (0.100-3) over (0.100-2) ...
Preparing to unpack .../21-libopeniscsiusr_2.1.3-5_amd64.deb ...
Unpacking libopeniscsiusr (2.1.3-5) over (2.1.2-1) ...
Preparing to unpack .../22-open-iscsi_2.1.3-5_amd64.deb ...
Unpacking open-iscsi (2.1.3-5) over (2.1.2-1) ...
Preparing to unpack .../23-pigz_2.6-1_amd64.deb ...
Unpacking pigz (2.6-1) over (2.4-1+b1) ...
Preparing to unpack .../24-popularity-contest_1.71_all.deb ...



Setting up vim-tiny (2:8.2.2434-3) ...
Setting up man-db (2.9.4-2) ...
Updating database of manual pages ...
man-db.service is a disabled or a static unit not running, not starting
it.
Setting up open-iscsi (2.1.3-5) ...
open-iscsi postinst: since the check in preinst some iSCSI sessions
have
                     failed. -> will wait 30s for automatic recovery
Setting up usbutils (1:013-3) ...
Setting up fdisk (2.36.1-8) ...
Setting up grub-common (2.04-20) ...
Installing new version of config file /etc/grub.d/30_uefi-firmware ...


and

root@debian-sanboot:~# multipath -ll
sanroot (3600140561d8bb00b25143b38318ce2c0) dm-0 LIO-ORG,debsanboot
size=8.0G features='1 queue_if_no_path' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=50 status=active
| `- 2:0:0:0 sda 8:0  active ready running
|-+- policy='service-time 0' prio=50 status=enabled
| `- 3:0:0:0 sdb 8:16 active ready running
|-+- policy='service-time 0' prio=50 status=enabled
| `- 4:0:0:0 sdc 8:32 active ready running
`-+- policy='service-time 0' prio=50 status=enabled
  `- 5:0:0:0 sdd 8:48 active ready running

root@debian-sanboot:~# iscsiadm -m session
tcp: [1] 172.16.20.40:3260,1 iqn.2003-01.org.linux-iscsi.debian.sanboot
(non-flash)
tcp: [2] 172.16.20.41:3260,1 iqn.2003-01.org.linux-iscsi.debian.sanboot
(non-flash)
tcp: [3] 172.16.20.43:3260,1 iqn.2003-01.org.linux-iscsi.debian.sanboot
(non-flash)
tcp: [4] 172.16.20.42:3260,1 iqn.2003-01.org.linux-iscsi.debian.sanboot
(non-flash)


So from the information I have, my suspicion was correct. The oddity
must be in your setup. The defaults must have been overridden for a
good reason. There's also the possibility that your network may have a
glitch. It is not easy for me to guess.

And with limited volunteer time, there's only a subset of the default
settings/combinations I can test at my end.


I suggest this bug be done as I don't see any issue. But I'll let you
make that call.

Giving that I have seen this bug before with my machines, it is only
the first time I am reporting and being the first reporter so I am
with you, this is some setting in my site or my machine.

With more reasearch with help from the local specialist I found a
an extra iSCSI setup to a local appliance that I not longer need.  So
I remove it from /etc/iscsi.  Doing again a:

dpkg --configure -a

Setting up open-iscsi (2.1.3-5) ...
open-iscsi postinst: since the check in preinst some iSCSI sessions have
                     failed. -> will wait 30s for automatic recovery
Processing triggers for initramfs-tools (0.140) ...
update-initramfs: Generating /boot/initrd.img-5.10.0-8-amd64


This time it succeeds.  So this probably is a problem on my machine.
May I suggest for you to increase the timeout from 30s to 60 or 120s?

Mine reasoning is that my machine boots fast enough for me not
investigate more my iSCSI connections, but probably the iSCSI
appliance is giving authentication timeout and so the increased need
for a longer timeout on open-iscsi postinst.  Making the package more
robust.

We may talk more about this problem and I offer my time and machine to
do research on to improve the package if you see benefit on that.  But
I will not keep the bug open if you want to close it.

Kind regards
Jose M Calhariz

Great. Thanks for the testing on another setup.

The thing about timeouts is that there's no sweet spot. 30s must have
been chosen keeping the Linux SCSI Mid-Layer in mind.

This is all TCP so the recovery should be instantaneous on the
transport side. On top of that, iSCSI with its default settings, will
do a ping health check every 5 seconds.

No rush as such. I just proposed so, after brief validation on my
setup.