On 01/09/2013 03:36 AM, Zsolt Ero wrote: > What my final solution is to disable the rcS.d and just call it in > rc.local after a sleep 5. This was the only way to be 100% sure that no > errors were present at the log. If I didn't do any sleep, it worked but > there was still an error first, and then 2 seconds later everything was ok. > > My VPS host told me that it's probably because the IPv6 address is > received from network while the IPv4 address is manually specified. So > it might take a few seconds to get the address. I guess the problem is > either: > 1. iscsi is testing for _any_ network connectivity, so when IPv4 is > ready then it tries to connect even though the IPv6 isn't. A fix would > be to test using the actual interface, not just using any network > connectivity (might be hard to implement).
We can add tests to iscsi to check if the proper network interface is up, but that will only allow us to speed up the start up process. If the network we need is not up, we can skip trying to login. Adding checks alone would not allow us to restart the iscsi service later when the network is up properly. The problem is iscsi does not start itself. Something like some hotplug scripts or init/systemd stuff calls it. It differs from distro to distro. That entity that calls iscsi would need to know that the network is up in a way iscsi can use it and then call iscsi. I think some distros just call iscsi anytime there is a network change like a interface coming up or a interface getting a address. > 2. Or yes, an alternative fix might be to just increase the tryout number. > 3. Or maybe what's happening is that since the interface doesn't exists > it doesn't starts trying again, but terminates the whole process, since > there was no interface at that time. I guess this was happening in my case. iscsi is going to try and do a connect() when it is started. It has zero smarts. It assumes when you tell it to login the network is ready to go. It is going to retry for the login retries count not matter what error is returned. This was actually added because we saw the host no reachable error case. > > Also, there is a bug in the Debian package, `modprobe > scsi_transport_iscsi` is missing, while the other 2 modprobes are > present. It'll take some time for everyone trying to install iscsi to You shouldn't need to modprobe scsi_transport_iscsi. The iscsi_tcp module depends on libiscsi which depends on scsi_transport_iscsi. If depmod has run ok, then when you load iscsi_tcp it should load iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi automatically. What error do you get when you run modprobe iscsi_tcp manually? > figure out that this modprobe is missing and you have to add it manually > to /etc/modules. Also, making a change like this permanent in modules > isn't really an elegant solution, so adding that line in the Deb 6 > packages would be important. Are the maintainers present on this forum? > Sending a bug report for Debian is such a hassle, I'd be happy if I > could just reach them here. > I think so. Is it still Ritesh? -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
