Debugging Controlled Access Mode
By ThinGuy on Jul 14, 2006
Editors Note: This debugging method no longer applies to SRSS 4.0 and Kiosk Mode. See the presentation on this post for more details:
Desktop Virtualization Days
When deploying applications via Controlled Access Mode, you are in some regards blind to what's really going on in the session. For instance if you were to try to launch rdesktop as a critical application and unbeknownst to you, your script that is called by CAM had a typo in it. In this case you'd only see cycling on the Sun Ray. Or perhaps Rdesktop was looking for a library that wasn't properly pathed in the CAM environment, yet worked just fine in a full Solaris desktop session.
Typically I always recommend that a customer create a CAM application that launches a terminal and that you try to test your CAM script from that terminal. It's important that your CAM script contains command set -x up at the top of the script so the actions that the CAM script performs become verbose.
If that's not deep enough you can watch the entire setup and tear down of a CAM session by turning on the debug option in the kiosk.start file. You'll still want to have set -x in your CAM script as well.
Twenty or so lines down you will find this:
# exec 2>/var/tmp/bbkiosk.$DISPLAY.$$ 1>&2 # Debug
# set -x
# set -u
exec 2>/dev/null 1>&2
Change this to this:
exec 2>/var/tmp/bbkiosk.$DISPLAY.$$ 1>&2 # Debug
# set -u
#exec 2>/dev/null 1>&2
Outside of the creation of the log files this is non-invasive. No restart or other changes need to take effect to make this happen. As new CAM sessions start, debug files will start up in /var/tmp for each CAM Session.
Feel free to change the path if you want to contain the debug files in a different location.