Logic to determine expected number of running session wrong (regression in hardy's open-iscsi 2.0.865-1ubuntu3.1)

Mathias, Dustin, could you look at what should be changed to fix this bug in karmic, and prepare an SRU for hardy if you think it's appropriate?

Well, since nobody else seems to be interested in dealing with this regression, here's a debdiff that I believe should fix at least the bug that I'm experiencing. I've uploaded the diff to my PPA (https://launchpad.net/~broder/+archive/ubuntu-tests), but due to the fact that all of my servers using iSCSI are in production use right now, I don't have any way to test the fix.

This is also happening in oneiric ocelot package 2.0.871-0ubuntu9.

Running the following:
iscsiadm -m discovery -t st -p 169.169.169.12
iscsiadm -m node -T "iqn.2008-08.com.starwindsoftware:-testing" -v automatic --portal "169.169.169.12"

automatically creates a folder structure like:
/etc/iscsi/nodes/iqn.2008-08.com.starwindsoftware\:-testing/169.169.169.12\,3260

thus it never automatically starts because the following init.d script chunk never runs properly.
ISCSI_TARGET_NB=$(cat /etc/iscsi/nodes/*/*/default 2>/dev/null| grep -c automatic)
ISCSI_SESSION_NB=$($ADM -m session 2>/dev/null | grep -c ^)
if [ "${ISCSI_TARGET_NB}" -ne "${ISCSI_SESSION_NB}" ]; then
        $ADM -m node --loginall=automatic > /dev/null
        udevadm settle
fi

Two possible workarounds:
Change ISCSI_TARGET_NB=$(cat /etc/iscsi/nodes/*/*/default 2>/dev/null| grep -c automatic) to ISCSI_TARGET_NB=$(cat /etc/iscsi/nodes/*/* 2>/dev/null| grep -c automatic)

or

mkdir /etc/iscsi/nodes/iqn.2008-08.com.starwindsoftware\:-testing/automatic
echo "automatic" >> /etc/iscsi/nodes/iqn.2008-08.com.starwindsoftware\:-testing/automatic/default

Status changed to 'Confirmed' because the bug affects multiple users.

This issue is present in Lucid, exactly as described for Hardy.

Marked Bug #1001535 as duplicate of this one.

The core of problem here is, Ubuntu modifications of open-iscsi was based on the braindead Debian versions *four years ago*, and no attempt of rebasing the work on recent Debian package (which at least reverts some of the stupid 'features' and eliminate some of the bugs against open-iscsi package) is done at all.

Broder, this approach is not sufficient to fix problem, because if I set both 'node.startup' and 'node.conn[0].startup' to automatic, then the result from grep would be double counted, so ${ISCSI_TARGET_NB} and $ISCSI_SESSION_NB} never ever match. It's mere lucky that iscsiadm --loginall will still be triggered (and only executed once), and doesn't do anything harmful.

I can confirm I have also encountered the same issue and arrived at the same conclusion.

FWIW the node.conn[0].startup varialbe does not seem to get set to automatic when you discover targets with the automatic start-up variable set in your iscsid.conf. So the scenario outlined in Abel's post #8 would only occur if you are manually setting that value.

I did a bit of googling and it seems that Ben Beuchler has already asked the question regarding node.startup Vs. node.conn[0].startup on the open-iscsi group:

https://groups.google.com/forum/?fromgroups=#!topic/open-iscsi/RnkgDuMyN0A

It appears that it shouldn't be necessary to set both variables.

Hardy has seen the end of its life and is no longer receiving any updates. Marking the Hardy task for this ticket as "Won't Fix".

Thank you for taking the time to report this bug. In an effort to keep an
up-to-date and valid list of bugs to work on, I have reviewed this report
to verify it still requires effort and occurs on an Ubuntu release in
standard support, and it does not:

We have a new documentation in place that might help anyone facing this issue:
https://ubuntu.com/server/docs/service-iscsi

The node.conn[0] is a leftover from the time open-iscsi supported multiple
connections per session, and it does not nowadays but kept compatibility.
Automatic and manual seems fine in latest versions.

It is unfortunate that we were unable to resolve this defect, however
there appears to be no further action possible at this time. I am
therefore moving the bug to 'Fix Released'. If you disagree or have
new information, we would be grateful if you could please add a comment
stating why and then change the status of the bug to 'New'.