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: [email protected] > http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev > Home Page: http://linux-ha.org/ _______________________________________________________ Linux-HA-Dev: [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
