On 07/14/2010 12:56 PM, Boaz Harrosh wrote:
On 07/14/2010 08:23 PM, Mike Christie wrote:
On 07/14/2010 10:49 AM, Boaz Harrosh wrote:
On 07/14/2010 05:52 PM, Mike Christie wrote:
On 07/14/2010 05:30 AM, HIMANSHU wrote:
How can we know error status of iscsiadm commands like
discovery,login,logout.
I think,all of them directly returns corresponding success/failure
messages.
so mostly I can just fire the commands without checking any error
codes after it?
If you run
iscsiadm -m node .... -l
iscsiadm should return a error code like other programs. If you wanted
to see it you could do
iscsiadm -m node .... -l
echo $?
Speaking of which. When I want to completely run from a script file
I currently have two ugly loops
after starting the iscsi service and before I can iscsiadm I must do:
start_iscsi_intiator()
{
if ! service $ISCSI status; then
service iscsi start ;
until cat /sys/class/iscsi_transport/tcp/handle 2>/dev/null ; do
sleep 1;
done
fi
}
Effectively wait for the /sys/class/iscsi_transport/tcp/handle file to appear
And after login but before I can actually start banging on my scsi device I
need:
login_iscsi()
{
echo login into: $IP_ISCSI
$iscsiadm -m discovery -t sendtargets -p $IP_ISCSI --login;
until ls $DEV_ISCSI 2>/dev/null; do sleep 1; done
}
Effectively wait for the device to appear. This one is particularly nasty
because it assumes that I know what $DEV_ISCSI will be.
Would we want to add a --wait-server and --wait switches to iscsiadm
--wait-server - will wait for the iscsi-kernel-modules and iscsid server
to stabilize. (until some timeout)
Not sure. When service iscsi start is run, it will eventually load the
modules. The script does not return until modprobe has returned and
modprobe does not return until the kernel module module_init function
and those do not return until it has run the sysfs functions that create
the files you are waiting on. So are you saying that once module_init
has completed the files are not accessible right away?
OK, so I just got lucky here probably, since I'm doing a sleep 1;
so the first iteration fails then a 1 sec wait is good enough. I think
what happens is that the iscsid server is not yet ready for communication
with iscsiadm. I'll remove the wait and run with debug-on see what actually
fails.
See open-iscsi/usr/iscsid_req.c:iscsid_connect(). Sometimes we will try
again. Sometimes we will not. We used to always retry, but in some
release we added that check for ECONNREFUSED, and then we added the
stuff to start iscsid. Maybe we need to change that test.
--wait - with a --login will wait (with timeout) until the loggedin
device is available.
For this one, the --login command returns once the scsi kernel scan is
completed (the tools just do write(/sys/class/scsi_host/hostX/scan). So
the kernel inquiries and report luns and scsi_device struct stuff is
done, and the kernel has sent hotplug events to notify userspace. So the
problem you are hitting is that things like udev have not handled the
hotplug event and created the /dev links right?
We could just add a wait in iscsiadm or the iscsi init scripts for this.
It would basically do
iscsiadm -m ... --login
iscsiadm -m session -P 3 | grep some_string_to_get_devices
wait on each device
Yes something like this, which is what I do. Perhaps just give
an example script with the recommended way to do it. (or add the --wait)
init scripts with auto-login work fine. It's only if I run the complete
lot from script as above .ie
start_iscsi_intiator
login_iscsi
mount_dev
Then I need these two waits above. otherwise it fails.
It's not urgent just if you can think about it a bit
The scripting is what will take me some time :) (I am not good at it).
--
You received this message because you are subscribed to the Google Groups
"open-iscsi" group.
To post to this group, send email to open-is...@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.
