-- Updated System Information: Debian Release: 10.0 APT prefers proposed-updates APT policy: (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64)
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?
pEpkey.asc
Description: application/pgp-keys
