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.

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________________
Linux-HA-Dev: [email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

Reply via email to