The only thing I'd add, and it gets back to Jörg's platform question, is making sure the script itself is getting sourced. If Linux, it has to end in .sh or it won't get sourced. Or perhaps there's another problem with the script, does it run fine if you call it manually? Pathed correctly? In a kiosk environment, the paths aren't the same as a regular session, so a script that works in one, may fail in another. Things that call binaries in openwin on Solaris is a good example.
Finally different revs of utilities behave slightly different. Some versions of Linux xset are not DPMS aware. That very critical part of the the script could be failing, almost silently. Put set -x atbyhe top of the script and check the session logs. FWIW, another good example of a utility that has platform and rev differences is zenity. Frustrating, hair loss inducing differences that aren't documented. ;) On Feb 26, 2013, at 1:16 AM, Jörg Barfurth <[email protected]> wrote: > Hi Paul, > > Am 25.02.13 17:28, schrieb Paul Evans: >> On 25/02/2013 11:21, Jörg Barfurth wrote: >>> Sun Ray 1 does not have a poweroff feature... >> Hi Jörg, >> Ah! >>> What you are probably seeing is screen blanking. The best discussion >>> of this, with all bells and whistles, is surely >>> <https://blogs.oracle.com/ThinkThin/entry/one_blank_to_rule_them>. >> Done all that. > > You didn't tell us your server platform. There may be some platform-specific > energy-saving mechanism that you haven't considered yet. > > Otherwise I have no more ideas. It would take some deeper debugging to find > out where the blanking is triggered. > > I'd probably start by running a background script that occasionally logs > 'xset -q' and 'utset' results for the display/session while your kiosk stuff > is running. And check for all kinds of screensaver or energy-saving related > things. > >>> If you still care about this: could you post utquery results for one >>> of your DTUs >> Also gone in through the gui on the DTU and set the Blanking to 0 as a >> trial, still goes black after 5 minutes. >> >> terminalID=0003ba141078 >> terminalIPA=25.60.18.200 >> model=CoronaP4 >> currentAuth=25.60.18.30 >> currentFW=GUI4.2_140993-06_2010.10.08.21.53 >> currentBarrier=422 >> currentBarrierLevel=422 >> currentMTU=1500 >> Subnet=255.255.255.0 >> Router=25.60.18.1 >> MTU=1500 >> Broadcst=25.60.18.255 >> LeaseTim=86400 >> DHCPServer=25.60.18.30 >> AuthSrvr=25.60.18.30 >> AuthPort=7009 >> LogHost=25.60.18.30 >> FwSrvr=25.60.18.30 >> NewTVer=4.2_140993-06_2010.10.08.21.53 >> tftpSrvr=25.60.18.30 >> FWservType=conf >> speed=100F >> parmsVersion=GUI4.2_140993-06_2010.10.08.21.53 >> parmsBarrier=422 >> configMTU=1500 >> AltAuth=25.60.18.30 >> confNetType=DHCP >> confTftpSrvr=25.60.18.30 >> confServers=25.60.18.30 >> stopqon=0 >> bandwidth=100000000 > > So this DTU *has* loaded the .parms file (you can see that from the presence > of the "parmsVersion" key). It doesn't list the poweroff parameter, because > SR1 units don't support poweroff. > > IOW: you don't need to worry about .parms loading when looking at your > problem. > >> Have set up .xscreensaver correctly in the prototype and it is passed >> into the kiosk user home directory correctly. Call xset in the startup >> script for the slideshow with noblank as per the blog mentioned. > > IIRC the blog recommedns three xset calls altogether. If you have followed > that, it'll be hard to do more by mail. > > Cheers > > - Jörg > > > -- > Jörg Barfurth http://blogs.oracle.com/joergb > > Disclaimer: I am employed by Oracle. The statements and opinions > expressed here are my own and do not necessarily represent those > of Oracle Corporation. > _______________________________________________ > 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
