Problem with auto-starup on Debian 6

2013-01-08 Thread zsolt . ero
I'm having problem configuring open-iscsi on Debian 6 to automatically 
start-up. I've configured everything and if I manually run *invoke-rc.d 
open-iscsi restart* then it runs fine!

However after a simple reboot, nothing happens. This is the log in the 
daemon.log / syslog:

Jan  8 11:31:51 ssdkvm iscsid: iSCSI logger with pid=1985 started!
Jan  8 11:31:52 ssdkvm iscsid: transport class version 2.0-870. iscsid 
version 2.0-871
Jan  8 11:31:52 ssdkvm iscsid: iSCSI daemon with pid=1986 started!
Jan  8 11:31:53 ssdkvm iscsid: connection1:0 is operational now
.
Jan  8 11:32:18 ssdkvm iscsid: transport class version 2.0-870. iscsid 
version 2.0-871
Jan  8 11:32:18 ssdkvm iscsid: iSCSI daemon with pid=929 started!
*Jan  8 11:32:18 ssdkvm iscsid: cannot make a connection to 2a00:. 
(-1,101)*
*
*
Why is this happening? Is the network not up when this line is present? 
(possibly because of IPv6?) How can I fix it? Remove the line from rcS.d 
and append *invoke-rc.d open-iscsi start *to rc.local?

Regards,
Zsolt







-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/open-iscsi/-/gMNaQs8I6lsJ.
To post to this group, send email to open-iscsi@googlegroups.com.
To unsubscribe from this group, send email to 
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/open-iscsi?hl=en.



Re: Problem with auto-starup on Debian 6

2013-01-08 Thread Mike Christie
On 01/08/2013 05:39 AM, zsolt@gmail.com wrote:
> I'm having problem configuring open-iscsi on Debian 6 to automatically
> start-up. I've configured everything and if I manually run *invoke-rc.d
> open-iscsi restart* then it runs fine!
> 
> However after a simple reboot, nothing happens. This is the log in the
> daemon.log / syslog:
> 
> Jan  8 11:31:51 ssdkvm iscsid: iSCSI logger with pid=1985 started!
> Jan  8 11:31:52 ssdkvm iscsid: transport class version 2.0-870. iscsid
> version 2.0-871
> Jan  8 11:31:52 ssdkvm iscsid: iSCSI daemon with pid=1986 started!
> Jan  8 11:31:53 ssdkvm iscsid: connection1:0 is operational now
> .
> Jan  8 11:32:18 ssdkvm iscsid: transport class version 2.0-870. iscsid
> version 2.0-871
> Jan  8 11:32:18 ssdkvm iscsid: iSCSI daemon with pid=929 started!
> *Jan  8 11:32:18 ssdkvm iscsid: cannot make a connection to 2a00:.
> (-1,101)*
> *
> *
> Why is this happening? Is the network not up when this line is present?

Probably. It might be coming up. 101 is ENETUNREACH "Network is
unreachable", so the networking might be coming up while is also
starting up.

It might be that by the time you can log in and run commands, the
network is up so your invoke call then works.

Does Your iscsid.conf have the setting initial_login_retry_max? You can
try increasing this. Make sure that you have disabled remove invalid
portals that are not going to come up or we will wait on them, and also
remember to run iscsiadm -o update to update the existing settings
with the new value or rerun the discovery command.


> (possibly because of IPv6?) How can I fix it? Remove the line from rcS.d
> and append *invoke-rc.d open-iscsi start *to rc.local?
> 
> Regards,
> Zsolt
> 
> 
> 
> 
> 
> 
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "open-iscsi" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/open-iscsi/-/gMNaQs8I6lsJ.
> To post to this group, send email to open-iscsi@googlegroups.com.
> To unsubscribe from this group, send email to
> open-iscsi+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/open-iscsi?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To post to this group, send email to open-iscsi@googlegroups.com.
To unsubscribe from this group, send email to 
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/open-iscsi?hl=en.



Re: Problem with auto-starup on Debian 6

2013-01-09 Thread Zsolt Ero
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).
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.

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 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.

Regards,
Zsolt











On 8 January 2013 23:03, Mike Christie  wrote:

> On 01/08/2013 05:39 AM, zsolt@gmail.com wrote:
> > I'm having problem configuring open-iscsi on Debian 6 to automatically
> > start-up. I've configured everything and if I manually run *invoke-rc.d
> > open-iscsi restart* then it runs fine!
> >
> > However after a simple reboot, nothing happens. This is the log in the
> > daemon.log / syslog:
> >
> > Jan  8 11:31:51 ssdkvm iscsid: iSCSI logger with pid=1985 started!
> > Jan  8 11:31:52 ssdkvm iscsid: transport class version 2.0-870. iscsid
> > version 2.0-871
> > Jan  8 11:31:52 ssdkvm iscsid: iSCSI daemon with pid=1986 started!
> > Jan  8 11:31:53 ssdkvm iscsid: connection1:0 is operational now
> > .
> > Jan  8 11:32:18 ssdkvm iscsid: transport class version 2.0-870. iscsid
> > version 2.0-871
> > Jan  8 11:32:18 ssdkvm iscsid: iSCSI daemon with pid=929 started!
> > *Jan  8 11:32:18 ssdkvm iscsid: cannot make a connection to 2a00:.
> > (-1,101)*
> > *
> > *
> > Why is this happening? Is the network not up when this line is present?
>
> Probably. It might be coming up. 101 is ENETUNREACH "Network is
> unreachable", so the networking might be coming up while is also
> starting up.
>
> It might be that by the time you can log in and run commands, the
> network is up so your invoke call then works.
>
> Does Your iscsid.conf have the setting initial_login_retry_max? You can
> try increasing this. Make sure that you have disabled remove invalid
> portals that are not going to come up or we will wait on them, and also
> remember to run iscsiadm -o update to update the existing settings
> with the new value or rerun the discovery command.
>
>
> > (possibly because of IPv6?) How can I fix it? Remove the line from rcS.d
> > and append *invoke-rc.d open-iscsi start *to rc.local?
> >
> > Regards,
> > Zsolt
> >
> >
> >
> >
> >
> >
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "open-iscsi" group.
> > To view this discussion on the web visit
> > https://groups.google.com/d/msg/open-iscsi/-/gMNaQs8I6lsJ.
> > To post to this group, send email to open-iscsi@googlegroups.com.
> > To unsubscribe from this group, send email to
> > open-iscsi+unsubscr...@googlegroups.com.
> > For more options, visit this group at
> > http://groups.google.com/group/open-iscsi?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To post to this group, send email to open-iscsi@googlegroups.com.
To unsubscribe from this group, send email to 
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/open-iscsi?hl=en.



Re: Problem with auto-starup on Debian 6

2013-01-09 Thread Mike Christie
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 open-iscsi@googlegroups.com.
To unsubscribe from this group, send email to 
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/open-iscsi?hl=en.



Re: Problem with auto-starup on Debian 6

2013-01-09 Thread Richard Laager
On Thu, 2013-01-10 at 00:24 -0600, Mike Christie wrote:
> I think some
> distros just call iscsi anytime there is a network change like a
> interface coming up or a interface getting a address.

Ubuntu (and I'd guess Debian) does this (well, the on ifup part). It
also stops open-iscsi on ifdown. I just had to disable that today.
Imagine a virtualization host server. You create a new VM on a new VLAN.
You add the relevant bridge interface, bring it up, and *bam*, all your
existing, running VMs just lost access to their disks.

Likewise, you can't upgrade the open-iscsi package while anything is
using iSCSI devices, because it will stop and start the service.

I solved these problems by using dpkg-divert on the if-up.d and
if-down.d scripts to move them to open-iscsi.disabled and a custom
policy-rc.d script to disallow open-iscsi stops or restarts if any VMs
are running. Also, at least in my case, it's necessary to restart
libvirt-bin after restarting open-iscsi.

Are many people really using iSCSI via roaming network connectivity?

-- 
Richard


signature.asc
Description: This is a digitally signed message part