ISCSI LIO targetcli no config after reboot

[andy77]

Hi @ all,

I am expiriencing the problem that targetcli is not reloading the saved configuration in "/etc/rtslib-fb-target/saveconfig.json" after a reboot. So always after a reboot you need to do the command:

targetctl restore /etc/rtslib-fb-target/saveconfig.json

In the man page of targetcli there is something written about a service called "target.service" which does not exist on my system. The only service related to targetcli which I found was "rtslib-fb-targetctl" but this is allready running after a reboot.

Regards

 

[Stoiko Ivanov]

hm - seems to work here (just started a test-machine of mine with targetcli/targetctl) the service restoring the config is 'rtslib-fb-targetctl.service':
* `systemctl cat rtslib-fb-targetctl.service` shows this is still using the sysvinit script '/etc/init.d/rtslib-fb-targetctl' which runs

`targetctl restore` (which again defaults to using '/etc/rtslib-fb-target/saveconfig.json')

maybe check the complete journal for output from targetcli/targetctl

 

[andy77]

Hi, ok seems I found out the reason. Here the jounal of rtslib-fb-targetctl.service

Apr 01 14:40:53 storage1 systemd[1]: Starting LSB: Start LIO targets...
Apr 01 14:41:03 storage1 rtslib-fb-targetctl[7178]: Loading rstlib-fb targetctl: targetctlCould not create StorageObject vm-196-disk-0: Device /dev/storage/is
Apr 01 14:41:03 storage1 rtslib-fb-targetctl[7178]: Could not find matching StorageObject for LUN 1, skipped
Apr 01 14:41:03 storage1 rtslib-fb-targetctl[7178]: Could not find matching TPG LUN 1 for MappedLUN 1, skipped
Apr 01 14:41:03 storage1 rtslib-fb-targetctl[7178]: .
Apr 01 14:41:03 storage1 systemd[1]: Started LSB: Start LIO targets.

Seems that the device in not online at the moment when the service tries to load it. A few seconds later, when I run the restore config manually, the devices are online, and the restore works fine.

Also having the same problem with VMs that has configured "start on boot" which also fales with the error:

No such file or directory

Because the devices are not ready immediately after the reboot of the node.

Any idea how to configure a delay?

Regards

 

[Stoiko Ivanov]

hmm - you could try to create a override snippet for the targetctl service and let it start after zfs-import.service (haven't tested it - since my testsetup does not run into this problem):
* `systemctl edit rtslib-fb-targetctl.service`
* enter into the editor:

[Unit]
After=zfs-import.target

* save and exit, reboot and hopefully it works

(you can verify that it worked by running `systemctl daemon-reload`, `systemctl show rtslib-fb-targetctl.service` (and looking for zfs-import))

hope this helps!

 

[andy77]

Did not helped unfortunately

 

[Republicus]

I know it's been some time since you asked this @andy77 but I've just experienced the same problem that persists in Debian Buster

To resolve:

1. Create the systemd unit file

nano /lib/systemd/system/target.service

[Unit]
Description=Restore LIO kernel target configuration
Requires=sys-kernel-config.mount
After=sys-kernel-config.mount network.target local-fs.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/bin/targetctl restore
ExecStop=/usr/bin/targetctl clear
SyslogIdentifier=target

[Install]
WantedBy=multi-user.target

2. Copy the unit file to /etc/systemd/system

cp /lib/systemd/system/target.service /etc/systemd/system/target.service

3. Give the unit file permissions:

chmod 644 /etc/systemd/system/target.service

4. Start and Enable the Service

systemctl start target
systemctl enable target

5. Check the status of the service:

systemctl status target

6. Reboot system to verify

reboot

7. Verify ConfigFS load on startup

targetcli ls

 

[azad]

I know it's been some time since you asked this @andy77 but I've just experienced the same problem that persists in Debian Buster

To resolve:

1. Create the systemd unit file

nano /lib/systemd/system/target.service

[Unit]
Description=Restore LIO kernel target configuration
Requires=sys-kernel-config.mount
After=sys-kernel-config.mount network.target local-fs.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/bin/targetctl restore
ExecStop=/usr/bin/targetctl clear
SyslogIdentifier=target

[Install]
WantedBy=multi-user.target

2. Copy the unit file to /etc/systemd/system

cp /lib/systemd/system/target.service /etc/systemd/system/target.service

3. Give the unit file permissions:

chmod 644 /etc/systemd/system/target.service

4. Start and Enable the Service

systemctl start target
systemctl enable target

5. Check the status of the service:

systemctl status target

6. Reboot system to verify

reboot

7. Verify ConfigFS load on startup

targetcli ls

Thank you so much for saving my day. I cannot see this issue being addressed anywhere in Debian related forums or support

 

[maestrotr]

Hey Republicus. Thank you very much for this solution.
I am not a proxmox user, but this helped me so much. I like Ubuntu but targetcli-fb loses configuration after reboot. Just for this bug, I was using CentOS, which I do not like. Now my ubuntu with targetcli is back.

5 Stars for you.

I know it's been some time since you asked this @andy77 but I've just experienced the same problem that persists in Debian Buster

To resolve:

 

[azad]

Thank you so much for saving my day. I cannot see this issue being addressed anywhere in Debian related forums or support

Hmm one thing is still not persistent, after every reboot the portal IP configured is missing.