After installing and configuring the targets, specifying node.startup =
automatic doesn't get accounted, resulting in fatal service disruption
and requiring manual intervention.
Solution described in
https://serverfault.com/questions/246572/open-iscsi-does-not-login-into-targets-on-boot
no longer applies, since Debian has moved
on to Systemd, and /etc/network/if-up.d/open-iscsi script no longer exists.

Control: tag -1 +moreinfo

You need to provide more information.

* Does the iscsi/iscsid daemon service not start
* Does the iscsi automatic loging not occur

The integration with systemd may have nothing to do with the issue you
are facing.

Whatever the case, there will be logs. Please go through them and share
the relevant bits for this bug.

I don't know how much "+moreinfo" you need, Ritesh, without specifying
what do you really want to hear, but the only hint I get at system boot
(with systemd.log_target=kmsg systemd.log_level=debug) is this:

rc.local[413]: iscsiadm: initiator reported error (19 - encountered
non-retryable iSCSI login failure)

Which is misleading, since invoking "iscsiadm -m node -L all"
successfully connects after a login. And I must note, that even then it
only appears after creating and populating rc.local, without it issue
still reproduces, but there is no indication in either journald/console
logs, only silent failure.

This is useful. So from the information so far, it looks like your
network is not usable for the iscsi service, which immediately gives
up.

What is configuring your network ? But either way, the dependency chain
should take care of that.

What is the output of `iscsi.service` and `iscsid.service`
Both the services start after the network target is completed. So you
need to look at your network. I suspect that is at fault here.

I don't know much about your setup. But if you have systemd configured
default, all your system logs should be persistent and available
through journalctl.

Kernel: Linux 4.19.0-5-amd64 (SMP w/1 CPU core)
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8),
LANGUAGE=ru_RU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Package version: open-iscsi/stable,now 2.0.874-7.1 amd64 [installed]

Versions of packages open-iscsi depends on:
ii  debconf [debconf-2.0]  1.5.71
ii  libc6                  2.28-10
ii  libisns0               0.97-3
ii  libmount1              2.33.1-0.1
ii  lsb-base               10.2019051400
ii  udev                   241-5

Versions of packages open-iscsi recommends:
ii  busybox  1:1.30.1-4

I've managed to pull the service for maintenance, and upgraded it to
Debian 10. So far the issue still exists, so it's not only related to
oldstable release.
Network setup is fairly trivial:

/etc/network/interfaces:
source /etc/network/interfaces.d/*
auto lo
iface lo inet loopback

/etc/network/interfaces.d/ens18:
auto ens18
iface ens18 inet static
        address 192.168.1.3/24
        gateway 192.168.1.1

There's also a ens19 interface, but it's management-only, and only has
IP address assigned, no static routes/bonds/etc. Physically it's a VM on
PVE hypervisor, all connected via virtual bridge to a router, and the
target is located on a MS Windows Server by another admin, and iSCSI
performs as expected on other initiators like the ones on Synology DSM
and vmWare ESXi 6.x.

Journalctl shows that iscsid has been started (iscsi.service unit is not
present):

jul 24 16:19:19 nfs-server iscsid[372]: iSCSI logger with pid=375 started!
jul 24 16:19:19 nfs-server iscsid[375]: iSCSI daemon with pid=376 started!

But LUN is not mounted, requiring manual intervention with "iscsiadm -m
node -L all && systemctl restart iscsid nfs-kernel-server" in order to
drive to reappear.

Configuration files haven't changed since initial bugreport, both
iscsid.conf and default (inside /etc/iscsi/nodes/TARGETNAME/ADDRESS)
have 'node.startup = automatic' and 'node.conn[0].startup = automatic'
values in them.

I don't know it it's related, but I can't simply reboot the service with
an active iSCSI portal login, with a strange error:

connection1:0: ping timeout of 5 secs expired, recv timeout 5, last rx
4355513531, last ping 4355514784, now 4355516096
connection1:0: detected conn error (1022)

Shouldn't systemd take care of logout from the portal, when the unit is
stopping?

But the default Debian iSCSI setup works good.

root@debian-btrfs:~# systemctl status iscsi
● open-iscsi.service - Login to default iSCSI targets
   Loaded: loaded (/lib/systemd/system/open-iscsi.service; enabled; vendor preset: enabled)
   Active: active (exited) since Thu 2019-08-01 20:50:41 IST; 2min 19s ago
     Docs: man:iscsiadm(8)
           man:iscsid(8)
  Process: 407 ExecStartPre=/bin/systemctl --quiet is-active iscsid.service (code=exited, status=0/SUCCESS)
  Process: 408 ExecStart=/sbin/iscsiadm -m node --loginall=automatic (code=exited, status=0/SUCCESS)
  Process: 436 ExecStart=/lib/open-iscsi/activate-storage.sh (code=exited, status=0/SUCCESS)
 Main PID: 436 (code=exited, status=0/SUCCESS)

Aug 01 20:50:15 debian-btrfs systemd[1]: Starting Login to default iSCSI targets...
Aug 01 20:50:41 debian-btrfs iscsiadm[408]: Logging in to [iface: default, target: iqn.2003-01.org.linux-iscsi.debian.x8664, portal: 172.16.20.40,
Aug 01 20:50:41 debian-btrfs iscsiadm[408]: Logging in to [iface: default, target: iqn.2003-01.org.linux-iscsi.debian.x8664, portal: 172.16.20.41,
Aug 01 20:50:41 debian-btrfs iscsiadm[408]: Logging in to [iface: default, target: iqn.2003-01.org.linux-iscsi.debian.x8664, portal: 172.16.20.42,
Aug 01 20:50:41 debian-btrfs iscsiadm[408]: Logging in to [iface: default, target: iqn.2003-01.org.linux-iscsi.debian.x8664, portal: 172.16.20.43,
Aug 01 20:50:41 debian-btrfs iscsiadm[408]: Login to [iface: default, target: iqn.2003-01.org.linux-iscsi.debian.x8664, portal: 172.16.20.40,3260]
Aug 01 20:50:41 debian-btrfs iscsiadm[408]: Login to [iface: default, target: iqn.2003-01.org.linux-iscsi.debian.x8664, portal: 172.16.20.41,3260]
Aug 01 20:50:41 debian-btrfs iscsiadm[408]: Login to [iface: default, target: iqn.2003-01.org.linux-iscsi.debian.x8664, portal: 172.16.20.42,3260]
Aug 01 20:50:41 debian-btrfs iscsiadm[408]: Login to [iface: default, target: iqn.2003-01.org.linux-iscsi.debian.x8664, portal: 172.16.20.43,3260]
Aug 01 20:50:41 debian-btrfs systemd[1]: Started Login to default iSCSI targets.
root@debian-btrfs:~# systemctl status iscsid
● iscsid.service - iSCSI initiator daemon (iscsid)
   Loaded: loaded (/lib/systemd/system/iscsid.service; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2019-08-01 20:50:15 IST; 2min 53s ago
     Docs: man:iscsid(8)
  Process: 400 ExecStartPre=/lib/open-iscsi/startup-checks.sh (code=exited, status=0/SUCCESS)
  Process: 403 ExecStart=/sbin/iscsid (code=exited, status=0/SUCCESS)
 Main PID: 405 (iscsid)
    Tasks: 2 (limit: 2353)
   Memory: 4.9M
   CGroup: /system.slice/iscsid.service
           ├─404 /sbin/iscsid
           └─405 /sbin/iscsid

Aug 01 20:50:15 debian-btrfs systemd[1]: Starting iSCSI initiator daemon (iscsid)...
Aug 01 20:50:15 debian-btrfs iscsid[403]: iSCSI logger with pid=404 started!
Aug 01 20:50:15 debian-btrfs systemd[1]: Started iSCSI initiator daemon (iscsid).
Aug 01 20:50:16 debian-btrfs iscsid[404]: iSCSI daemon with pid=405 started!
Aug 01 20:50:41 debian-btrfs iscsid[404]: Connection2:0 to [target: iqn.2003-01.org.linux-iscsi.debian.x8664, portal: 172.16.20.41,3260] through [
Aug 01 20:50:41 debian-btrfs iscsid[404]: Connection1:0 to [target: iqn.2003-01.org.linux-iscsi.debian.x8664, portal: 172.16.20.40,3260] through [
Aug 01 20:50:41 debian-btrfs iscsid[404]: Connection4:0 to [target: iqn.2003-01.org.linux-iscsi.debian.x8664, portal: 172.16.20.43,3260] through [
Aug 01 20:50:41 debian-btrfs iscsid[404]: Connection3:0 to [target: iqn.2003-01.org.linux-iscsi.debian.x8664, portal: 172.16.20.42,3260] through [

THat is not strange. Your network went out before the LUNs were
unmounted and the iSCSI sessions terminated. So iSCSI is simply
complaining about the network outage.

Please check your setup. Either of the service may be not enabled.

It does. And it does well.

Same problem here. I feel this bug severity should be at least grave, as
this easily leads to data loss.