# ctld trying to start before networking is configured



## jem (May 7, 2021)

Hi.

I've just upgraded a 12.2-RELEASE system to 13.0-RELEASE, and during one of the reboots, I noticed that ctld was failing to start.

Scrolling back through the boot messages on the console, I noticed that it was only _after_ ctld tried to start that the network interfaces were configured.  After the kernel's hardware probing text finished (the bit in bright/bold), the rc messages were in this order:

```
Setting hostuuid: xxx
Setting hostid: xxx
Starting file system checks:
Mounting local filesystems:.
ELF ldconfig path: xxx
32-bit compatibility ldconfig path: xxx
Setting hostname: san.lab.home.arpa
Setting up harvesting: xxx
Feeding entropy: .
Starting ctld.
ctld: (several lines of ctld output, adding luns and ports and wotnot)
ctld: listening on 10.0.192.15, portal-group "vlan192"
ctld: bind(2) failed for 10.0.192.15: Can't assign requested address
ctld: listening on 10.0.193.15, portal-group "vlan193"
ctld: bind(2) failed for 10.0.193.15: Can't assign requested address
ctld: failed to apply configuration; exiting
Starting Network: lo0 em0 em1 em2 em3.
```

Upon logging into the system, as expected, ctld wasn't running and there was nothing listening on 10.0.192.15:3260 or 10.0.193.15:3260.

Anyone know why ctld is starting too early, before the network has even been reconfigured?  I don't recall having this issue with 12.2-RELEASE.


----------



## SirDice (May 7, 2021)

If I look at rcorder(8) that appears to be intentional, /etc/rc.d/ipsec for example is started too before NETWORKING is up. Which brings me to the solution, just add `NETWORKING` to the `REQUIRED` line in /etc/rc.d/ctld.


----------



## jem (May 7, 2021)

Thanks SirDice, that does the trick.

It's strange that some network services are being started before the network though.  Could this be a bug?


----------



## romihs (Apr 20, 2022)

Hi,

I'm not sure if I should be posting here, but since I attempted the suggestion here, I thought it would be appropriate.

I've just upgraded my FreeBSD file server to 13-RELEASE, and I had issues connecting to my iSCSI target from my other systems.

When I made the changes to /etc/rc.d/ctld to force the service to wait for NETWORKING to be up, it breaks my network; I'm not able to ping my gateway from the FreeBSD system, nor am I able to ping the FreeBSD system from another machine.
I set my Windows machine to ping the FreeBSD server, and rebooted the server. I noticed that the Win machine got a couple replies from the FreeBSD system as it's booting and then the it stops responding...

I removed NETWORKING from the REQUIRED line in /etc/rc.d/ctld, and rebooted the FreeBSD server, and again kept pinging it from the Win machine. Once the FreeBSD server boots up, it responds to pings continuously.
Checking the status of ctld I find that it is "not running" and when starting it I get:


```
root@xenfbsd:/root# service ctld start
Starting ctld.
ctld: /etc/ctl.conf is world-readable
ctld: error returned from port creation request: target "iqn.2019-11.myhost:win0" for portal group tag 257 already exists
ctld: failed to update port pg0-iqn.2019-11.myhost:win0
ctld: error returned from port creation request: target "iqn.2019-11.myhost:linux0" for portal group tag 257 already exists
ctld: failed to update port pg0-iqn.2019-11.myhost:linux0
```

A further discovery I've made is that if I disable the initiator in the Window machine by disconnecting from the target, and reboot the FreeBSD server, all pings to it are replied even after starting the ctld service.


I've looked through the system logs and have not found anything pointing as to why the ctld service does not start at boot up, I have the service enabled in /etc/rc.conf.


----------

