Art, sounds like the debugging could indeed be better implemented or at least documented.
to get the minimum you're asking below, put some debugging in your own script that determines which IP/WTS to connect to. i.e. have your own logging you can enable that'll write out things like "attempting connection to WTS <some IP>", etc. it's pretty terse but occasionally launching your solaris command with 'truss' and dumping the output to a file can give clues as to what's gong on. hope this helps.. Curtis. On Sat, Aug 20, 2011 at 11:06 AM, Art Peck <[email protected]> wrote: > I have no idea what error code 17 means exactly. I'm longing for the day > when SOMEONE publishes a list of the error codes uttsc spews and what they > mean and what troubleshooting steps would be appropriate, but alas, we are > still waiting. We have a nice set of tips for the OSD codes. If I missed it > or just need to RTFM, my apologies to the author. > > I have seen recently that I was getting lots of the error code 17's from > uttsc when it was trying to connect to a WTS that was wedged for some odd > reason. Port 3389 reported open, but the server was refusing connections. > The WTS console was displaying something about pagefile space being low and > that it was being increased. Clicking "OK" got no response whatsoever. We > wound up rebooting it which seems to have solved the immediate problem. > > I discovered this state by running uttsc from a terminal session. It would > exit immediately when I attempted to connect to one particular server. > Fortunately, it was one of the low-order servers in a group of 14 since I > had to connect to each in turn to see which one was failing. More > informative logger entries would be appreciated. How about "uttsc exiting > with error code 17 when connecting to blah"? Again, if I missed something in > the docs, my apologies. > > Secondary rant: There should be a way of enabling logging from the uttsc > commandline so that one can capture debug info for uttsc processes that are > starting and exiting rather quickly. SIGHUP of some process isn't useful, or > at least not for me. > > Art > -- > > > [image: Arthur H. Peck & Associates, LLC] Cell Phone > 904-614-7902 > Skype > 904-638-5056 > Email > [email protected] > Web > http://artpeck.net > > > _______________________________________________ > SunRay-Users mailing list > [email protected] > http://www.filibeto.org/mailman/listinfo/sunray-users > > -- Curtis Cunningham web: c <http://curtiscunningham.com>urtiscunningham.com<http://curtiscunningham.com>
<<art-peck-logo-200.png>>
_______________________________________________ SunRay-Users mailing list [email protected] http://www.filibeto.org/mailman/listinfo/sunray-users
