(I believe) You are seeing is a newish feature since 4.1 where it
attempts to fix load balancing when neither smart cards or nor NSCM is
being used. The old behavior was basically all DTU's would attach to
the the first available server and never move off unless they were power
cycled. So, while by design, it's somewhat unexpected to those who are
used to the pre-4.0 behavior.
Trust me, you're not the first person to have to question the DI state.
Perhaps we should have touted this as a feature (it really is), but we
considered it a bug that LB wasn't working as expected under non-card
kiosk sessions, so it's not called out specifically.
I'll work with our Wiki guru and put together something about it under
the troubleshooting section so at least if you google it, you can find
an answer.
On 9/17/10 6:51 PM, Michael Jinks wrote:
Hi Craig.
On Fri, Sep 17, 2010 at 04:41:18PM -0700, Craig Bender wrote:
Can you tell us a little bit about the environment. Smart cards, no
smart cards?
No smart cards.
Do non-card sessions Sun Rays are sit at the windows login
screen and timeout after 120 seconds of no-login? Or do they sit at
something else, then users insert smart card to get windows.
They wake up and go straight to uttsc. So, the former.
Depending on your scenario, those sessions in a DI state could be
sessions that got loadbalanced to the other server. Do they go away in
15 minutes?
Ack. From looking at this earlier I was sure that once a DTU serial
number showed up in the "idle sessions" list, it stayed there and didn't
appear in the active sessions. (And that may have been the behavior we
were seeing, say, before we got more Windows CALs. I do know for sure
that people were complaining about dead DTU's in at least one of our
sites.) Now though, for every serial number I find in the idle list, a
session for that DTU does appear as active on the other FOG member.
So, it looks like I've been chasing a non-issue.
Well good, but boy do I feel silly.
Thanks.
-mrj
On 9/17/10 4:04 PM, Michael Jinks wrote:
We have a two-server FOG, currently serving 151 sessions, all uttsc in
kiosk mode.
Sometime last week(?), we started to see sessions slipping into "DI"
state and sticking, and I haven't been able to figure out why.
We thought we were running out of licenses for our TS servers, and we do
have more traffic there than just our Sun Ray stuff, but after adding a
hundred CALs earlier today, the problem didn't appear to diminish.
If I kill the sessions marked "DI", they gradually come back, but others
go into disconnected state. It seems like we top out between 60 and 64
sessions per server, for a total of just over 120, with the remaining
sessions going DI. As far as I can tell, there's no pattern to which
DTU's get sick and which ones work.
I don't think it's a user account exhaustion issue; we have 200 utku*
users configured on each FOG member.
On the Windows side, our servers are busy, but not *that* busy. The
Windows crew has so far been unable to find any cause for the trouble in
their area.
I don't find anything in /var/opt/SUNWut/messages that looks related.
The only errors look like this:
Sep 17 18:04:02 blackstone Sun Ray Connector proxy:[27847]: [ID 855542
user.error] Child closed socket prematurely, session shutdow
...and we get quite a few of those, but they don't seem to coincide with
sessions going into DI state. Maybe they're related, maybe not, I can't
tell.
If I fire up a Sun Ray soft client, I can't duplicate the problem. I've
tried connecting to a test Sun Ray server for a JDS session and running
uttsc from a terminal there; I've also tried connecting the soft client
directly to the FOG where we're having trouble. In both cases, after a
few dozen tries, I've gotten a successful uttsc connection every time.
Any clues on where to look next?
Thanks,
--Michael
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
