Ok, here are a few more things you can try, which
may give some clues to what's happening.
First off, take a look in the target's log file.
It should look something like this:
[EMAIL PROTECTED]:~# cat /var/svc/log/system-iscsitgt\:default.log
[ Feb 9 21:11:50 Enabled. ]
[ Feb 9 21:11:52 Executing start method ("/lib/svc/method/svc-iscsitgt
start"). ]
[ Feb 9 21:12:02 Method "start" exited with status 0. ]
[ Feb 9 22:34:05 Stopping because service disabled. ]
[ Feb 9 22:34:08 Executing stop method ("/lib/svc/method/svc-iscsitgt stop
76"). ]
[ Feb 9 22:34:18 Method "stop" exited with status 0. ]
Check that the log file does not have any lines containing.
"Stopping because process dumped core"
If that's ok, then you could enable the debug log for the target:
For Solaris 10u4, this should do it:
Edit file "/etc/iscsi/target_config.xml"
Add a line "<qlog-lvl>0x0ffff</qlog-lvl>"
Restart daemon with "svcadm restart iscsitgt"
The debug out is located in file "/tmp/target_log"
Another thing you could try is to trace the flow
of execution in the target code, which you can do with DTrace.
This may give a clue to where in the iscsitgt code
thing are going wrong for you.
Brendan Gregg has written a small program that you
can use to trace any user-space process:
http://www.brendangregg.com/DTrace/dapptrace
Use it like this:
[EMAIL PROTECTED]:~# ps -ef | grep iscsi
root 659 1 0 01:15:43 ? 5:47 /usr/sbin/iscsitgtd
[EMAIL PROTECTED]:~# ./dapptrace -l -p 659
..so we use 'ps' to find the PID of the target.
Then we let dapptrace connect to that process.
The '-l' option allows you to see which thread the
function call is occurring on.
As your iscsi login seems to be terminating fairly early on,
then hopefully the trace will not be too long.
Best Regards
Nigel Smith
This message posted from opensolaris.org
_______________________________________________
storage-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
