At the end of your script the kiosk session exists, thus destroying all the
temporary user data and (I believe) resetting the X session for that particular
unit; a new session is then started, new kiosk user environment is setup, and
your shell script is executed again.
Since it's tearing down and setting up a new session it will take some time,
and even on some of the fastest Sun boxes it takes at least five (5) seconds to
restart once the kiosk session exists.
It seems like your 'fix' is actually keeping the parent kiosk session script
from exiting, so the session is not being killed and re-created. This should
be easy to verify, just run '# ptree -c' and you should see something like
/usr/dt/bin/dtlogin -daemon -udpPort 0
...
/bin/sh /etc/opt/SUNWkio/sessions/<session-name>/<session-script-name.sh>
/bin/sh /etc/opt/SUNWkio/sessions/<session-name>/<session-script-name.sh>
/bin/sh
/etc/opt/SUNWkio/sessions/<session-name>/<session-script-name.sh>
...
<uttsc command>
Where <session-name> is the name of your session and <session-script-name.sh>
is the name of your kiosk session script. You'll see that line repeat for
every time you 'Cancel' and select 'Connect to Windows' in your popup box.
Basically you're using a recursive (instead of an interative) approach to
looping, which should be avoided for many reasons.
A better solution would be to write a [while do done] block that keeps calling
uttsc within a certain timeout threshold (e.g. every 30 minutes). The UTTSC
session actually does this (hence the 'timeout' argument to uttsc session), so
I'd reference that session script for an example of how to do this.
That being said, if you have security concerns, there is a very good reason why
the kiosk session is completely destroyed after the kiosk script exists.
Looping internally in the kiosk script, possibly allowing numerous real users
to share the exact same kiosk session, has security (and audit) consequences,
but that depends on your business requirements.
Best Regards,
Nick Ross
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of David Markey
Sent: Tuesday, March 03, 2009 3:55 PM
To: SunRay-Users mailing list
Subject: Re: [SunRay-Users] Odd delay [and an even odder fix] in kiosk mode
I experience similar delays but i just assumed that because we're using
a t1000 and they're a pretty slow machine that it just didn't have
enough grunt.
Nishimura, Scott L (IT) wrote:
>
> I built a new SRS [Solaris 10/update 6, SRSS 4.1/SRWC 2.1]. Kiosk
> mode [no smart card] runs a Bourne shell script that eventually calls
> uttsc and connects to a WTS.
>
> If I cancel a Windows login [get to the screen that prompts for
> username/password/domain and hit “Cancel”], it takes ~13 seconds to
> get back to a Windows login. Does anyone else see this? It almost
> looks like it’s doing an X display reset [CTL ALT backspace backspace]
> the way the status box is displayed. /var/opt/SUNWut/log/messages has
> about 6 seconds of dead time after which I get an error about dtlogin
> not being able to open a display.
>
> Now comes the interesting part: I added a splash screen which puts up
> a customized picture and verbiage [uses “utmsgbox”]. The main choice
> is “connect to Windows” which runs the same Bourne shell script as
> referenced above. NOW if I cancel a login, I get back to the splash
> screen almost instantaneously [!]. So by ADDING a step [ostensibly],
> I’ve somehow sped up the delay.
>
> My theory is that by introducing the splash screen, I’ve somehow
> bypassed/overridden other processes. Trying to trace the process
> stack with ptree and truss got a bit tedious so I gave up [for now],
> especially since I had a faster solution.
>
>
> Scott
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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
