ISCSI LIO targetcli no config after reboot

andy77

Well-Known Member
Jul 6, 2016
248
13
58
40
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:
Code:
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
 
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
 
Hi, ok seems I found out the reason. Here the jounal of rtslib-fb-targetctl.service
Code:
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:
Code:
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
 
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:
Code:
[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!
 
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

Code:
[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
 
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

Code:
[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
 
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:
 
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.
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!