Mailing List Archive

Hi,

On Thu, Nov 10, 2011 at 10:11:30AM +0000, Matthew Richardson wrote:
> In newer versions of iscsid (RHEL6) the init.d script has been changed,
> such that the start method won't do anything unless discovery etc has
> already occurred at least once.
>
> As a result, there's now a new option in iscsid.conf - 'iscsid.startup'
> which you can set to be a command to be run when iscsiadm is unable to
> connect to the iscsid daemon:
>
> http://groups.google.com/group/open-iscsi/browse_thread/thread/afdaaedad9050da8

Interesting. Some people are bored.

> The iscsi RA shouldn't fail if it notices iscsid isn't running if this
> value is set - this patch checks the config file to see if it exists,
> and if it does, doesn't return an error.

OK. If that doesn't help, it's going to fail later anyway.

> One side-effect of this change in behaviour is that this startup will
> only be carried out for certain iscsiadm actions. Since (in RH anyway)
> the init.d script also loads the iscsi kernel modules, some actions in
> the RA will now fail if these modules haven't been loaded.

I'm not sure I understand this. How would it work without the RA?
Do people still need to invoke again /etc/init.d/iscsi start?
Aren't modules loaded anyway on start? If not, what loads them
later?

Did you already try this patch?

> The solution seems to be to 'manually' load the modules (e.g. via
> /etc/modprobe.d). I'm not sure if this will have HA effects, since this
> will be a 'one-off' operation, e.g at boot.
>
> Please let me know if you have any comments/suggestions on this patch,
> or think that a different approach to starting the iscsid daemon from
> the RA is now needed.

I'm not sure really.

Cheers,

Dejan

> Thanks,
>
> Matthew
>
>
>
> --
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.

> --- iscsi 2011-06-29 13:51:48.000000000 +0100
> +++ iscsi.new 2011-11-10 09:52:13.000000000 +0000
> @@ -160,6 +160,8 @@
> open_iscsi_daemon() {
> if ps -e -o cmd | grep -qs '[i]scsid'; then
> return 0
> + elif grep -qs '^iscsid.startup' /etc/iscsi/iscsid.conf; then
> + return 0
> else
> ocf_log err "iscsid not running; please start open-iscsi utilities"
> return 1
>




> _______________________________________________________
> Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> Home Page: http://linux-ha.org/

_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

On 10/11/11 12:39, Dejan Muhamedagic wrote:
> Hi,
>
> On Thu, Nov 10, 2011 at 10:11:30AM +0000, Matthew Richardson wrote:
>> In newer versions of iscsid (RHEL6) the init.d script has been changed,
>> such that the start method won't do anything unless discovery etc has
>> already occurred at least once.
>>
>> As a result, there's now a new option in iscsid.conf - 'iscsid.startup'
>> which you can set to be a command to be run when iscsiadm is unable to
>> connect to the iscsid daemon:
>>
>> http://groups.google.com/group/open-iscsi/browse_thread/thread/afdaaedad9050da8
>
> Interesting. Some people are bored.
>
>> The iscsi RA shouldn't fail if it notices iscsid isn't running if this
>> value is set - this patch checks the config file to see if it exists,
>> and if it does, doesn't return an error.
>
> OK. If that doesn't help, it's going to fail later anyway.
>
>> One side-effect of this change in behaviour is that this startup will
>> only be carried out for certain iscsiadm actions. Since (in RH anyway)
>> the init.d script also loads the iscsi kernel modules, some actions in
>> the RA will now fail if these modules haven't been loaded.
>
> I'm not sure I understand this. How would it work without the RA?
> Do people still need to invoke again /etc/init.d/iscsi start?
> Aren't modules loaded anyway on start? If not, what loads them
> later?

I'll try to explain the side-effect a bit better if I can.

Previously, running the iscsid init script would try to load iscsid
kernel modules, then launch the daemon. However, the changes to the
script causes it to not start if iscsid has never run before on the
system, unless you call it with 'force-start' instead of just 'start'.

In what seems to be a big hack, it looks like the iscsid.startup value
is recommended (on RH anyway) to be '/etc/rc.d/init.d/iscsid
force-start' which should give the same effect as most people achieved
before using an lsb primitive rule to call this script.

The problem is that iscsiadm discoverydb commands need the kernel
modules loaded before they will call the startup command, so you have
to load them beforehand elsewhere:

/tmp$ iscsiadm -m discoverydb -p 192.168.140.10:3260 -t sendtargets -D
iscsiadm: Could not scan /sys/class/iscsi_transport.
iscsiadm: iSCSI driver tcp is not loaded. Load the module then retry the
command.
iscsiadm: Could not perform SendTargets discovery: iSCSI driver not
found. Please make sure it is loaded, and retry the operation

/tmp$ modprobe iscsi_tcp

/tmp$ iscsiadm -m discoverydb -p 192.168.140.10:3260 -t sendtargets -D
Starting iscsid: [ OK ]
192.168.140.10:3260,1 iqn.2010-05.uk.ac.ed.eng:w3718


Hopefully this all makes sense (the explanation and the patch, not the
change to iscsid :) )

>
> Did you already try this patch?
>

Yes, I'm running it on my test systems without any apparent problems
(though I am having to load the kernel modules at boot).

Thanks,

Matthew

--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

On Thu, Nov 10, 2011 at 04:10:29PM +0000, Matthew Richardson wrote:
> On 10/11/11 12:39, Dejan Muhamedagic wrote:
> > Hi,
> >
> > On Thu, Nov 10, 2011 at 10:11:30AM +0000, Matthew Richardson wrote:
> >> In newer versions of iscsid (RHEL6) the init.d script has been changed,
> >> such that the start method won't do anything unless discovery etc has
> >> already occurred at least once.
> >>
> >> As a result, there's now a new option in iscsid.conf - 'iscsid.startup'
> >> which you can set to be a command to be run when iscsiadm is unable to
> >> connect to the iscsid daemon:
> >>
> >> http://groups.google.com/group/open-iscsi/browse_thread/thread/afdaaedad9050da8
> >
> > Interesting. Some people are bored.
> >
> >> The iscsi RA shouldn't fail if it notices iscsid isn't running if this
> >> value is set - this patch checks the config file to see if it exists,
> >> and if it does, doesn't return an error.
> >
> > OK. If that doesn't help, it's going to fail later anyway.
> >
> >> One side-effect of this change in behaviour is that this startup will
> >> only be carried out for certain iscsiadm actions. Since (in RH anyway)
> >> the init.d script also loads the iscsi kernel modules, some actions in
> >> the RA will now fail if these modules haven't been loaded.
> >
> > I'm not sure I understand this. How would it work without the RA?
> > Do people still need to invoke again /etc/init.d/iscsi start?
> > Aren't modules loaded anyway on start? If not, what loads them
> > later?
>
> I'll try to explain the side-effect a bit better if I can.
>
> Previously, running the iscsid init script would try to load iscsid
> kernel modules, then launch the daemon. However, the changes to the
> script causes it to not start if iscsid has never run before on the
> system, unless you call it with 'force-start' instead of just 'start'.
>
> In what seems to be a big hack, it looks like the iscsid.startup value
> is recommended (on RH anyway) to be '/etc/rc.d/init.d/iscsid
> force-start' which should give the same effect as most people achieved
> before using an lsb primitive rule to call this script.
>
> The problem is that iscsiadm discoverydb commands need the kernel
> modules loaded before they will call the startup command, so you have
> to load them beforehand elsewhere:
>
> /tmp$ iscsiadm -m discoverydb -p 192.168.140.10:3260 -t sendtargets -D
> iscsiadm: Could not scan /sys/class/iscsi_transport.
> iscsiadm: iSCSI driver tcp is not loaded. Load the module then retry the
> command.
> iscsiadm: Could not perform SendTargets discovery: iSCSI driver not
> found. Please make sure it is loaded, and retry the operation
>
> /tmp$ modprobe iscsi_tcp
>
> /tmp$ iscsiadm -m discoverydb -p 192.168.140.10:3260 -t sendtargets -D
> Starting iscsid: [ OK ]
> 192.168.140.10:3260,1 iqn.2010-05.uk.ac.ed.eng:w3718
>
>
> Hopefully this all makes sense (the explanation and the patch, not the
> change to iscsid :) )

Oh, yes, it does. I was just hoping that it wouldn't be this
ridiculous.

> > Did you already try this patch?
> >
>
> Yes, I'm running it on my test systems without any apparent problems
> (though I am having to load the kernel modules at boot).

I'll apply the patch, but anyway people will need to deal with
loading modules themselves.

Many thanks for the contribution.

Cheers,

Dejan

> Thanks,
>
> Matthew
>
> --
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
>



> _______________________________________________________
> Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> Home Page: http://linux-ha.org/

_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/