Error codes/return values of iscsiadm commands
HIMANSHU
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?
I will really appreciate any help.
Thank you.
HIMANSHU
Mike Christie
> 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 $?
Does that answer your question?
Boaz Harrosh
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)
--wait - with a --login will wait (with timeout) until the loggedin
device is available.
How can it be done?
Boaz
Mike Christie
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?
> --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
Boaz Harrosh
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.
>
>
>> --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
Thanks
Boaz
Mike Christie
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).
Mike Christie
Oh yeah, Hannes had thought he saw what you are seeing too. Different
sysfs files though. I thought they should be created/ready by the time
we return from the module_init functions. I might be wrong or there
might be a bug in the sysfs code? I did not hear back from Hannes.
HIMANSHU
Yes,I generally do it using $? for other linux commands,but somehow
not comfortable doing it here.
iscsiadm -m ... >sucess 2>failure
and if file is non-empty,print the contents accordingly is what I can
think of.
It might be very ugly way of doing it.
Mike Christie
> Thanks for replies.
>
> Yes,I generally do it using $? for other linux commands,but somehow
> not comfortable doing it here.
>
> iscsiadm -m ...>sucess 2>failure
> and if file is non-empty,print the contents accordingly is what I can
> think of.
> It might be very ugly way of doing it.
>
Yeah, I think some versions did not print out error codes correctly so
for the redhat/fc scripts we have this for some commands:
$exec -m node --logoutall=automatic 2>&1 > /dev/null | grep iscsiadm
# <sigh> iscsiadm does not always give a non 0 exit status in case of
# error so we grep for any messages to stderr and see those as
errors too
if [ ${PIPESTATUS[0]} -ne 0 -o ${PIPESTATUS[1]} -eq 0 ]; then
failure $"Stopping $prog"
echo
return 1
fi