Re: [Wrapper-user] GUI based application's startup failed on Solaris 8 reboot

[Leif M. <le...@ta...>]

Yasir,
    Sorry I hadn't yet gotten back to you.  Line feeds were my next 
guess.  Glad you got
that part working.

    First a question from me. :-)  I don't have all that much experience 
with Solaris, and
my past requests had gone unanswered.   Do you know enough about Solaris 
to be able
to tell me whether or not my instructions for getting the Wrapper 
installed to boot on
startup are correct.  I know that it works, but I am especially unsure 
about the boot
order numbers for the various run levels.  The values that I described 
are good defaults
for Linux, but they may need to be different for Solaris.

    Now on to your question.  The short answer is that that is a 
difficult problem with
all applications that start on bootup on UNIX machines.   In general, 
applications that
start at boot up should not require access to a DISPLAY as it will in 
general not be
available.  This is very different from the Windows world.
    In many cases, a DISPLAY will only be made available for users 
connecting
from a remote terminal for example.

    If it only makes sense to run your application in an environment 
where a DISPLAY
is available, then you should be launching it when a user logs in to X 
Windows rather
than when the system boots.

    Often you will want to have the program running "headless" in the 
background and
then display a GUI when a user logs on.  You get this behavior for free 
on Windows
when installing as an NT service.   On UNIX however, due to a number of 
reasons,
including security issues, this is not really possible.   To get around 
this, you would
create a second application that is launched manually or when the user 
logs on.  This
second application would then connect to the first headless app and act 
as its GUI.
    Yes, I know it is complicated.  But those are the only ways that I 
know to
accomplish what you are asking.   As I said, this is true for all UNIX 
apps and does
not really have anything to do with the Wrapper.

    One idea (untested) would be to try to set the DISPLAY variable 
manually when
launching the Wrapper (or JVM via a setting in the wrapper.conf).   You 
could then
have your application attempt to show its display.  If it fails, you 
would catch the
exception that you saw, then wait for 30 seconds or so.  Then call
WrapperManager.restart().   When the JVM restarted it would once again 
attempt
to show its GUI.  If the user had logged on by then the GUI may come 
up.  This is
a guess however.  There may be something else that will prevent this 
from working.

    Please post back with any results and of course with any solution 
that you may
come up with.  I, and I'm sure others, would be interested in hearing them.

Cheers,
Leif

Yasir Khan wrote:

> Hi,
>  
> My problem "Unable to run start script on Solaris 8" is solved and I 
> am able to run the script successfully. The problem was that I edited 
> the script on Windows 2000 system and then copied it to the Solaris 8 
> system. And due to the difference in 'new line' character in Windows 
> and Solaris the script is corrupted and is failed when run on Solaris. 
> When I edited the script on Solaris system, it started working fine. :-)
>  
> Now I have created the proper symbolic links according to 
> documentation to start my application automatically on Solaris reboot. 
> Things starts working fine on reboot but when GUI display code is 
> executed the application crashes, there might be the reason (that I 
> can guess from the error message) that X Window Server is not started 
> at the time when my application tried to display GUI. Now how can I 
> fix my problem ... ?
>  
> Following are the commands that I used to create symbolic links [tf is 
> the name of application and the script].
>  
> ln  -s /usr/tf/tf /etc/init.d/tf
> ln  -s /etc/init.d/tf  /etc/rc0.d/K20tf
> ln  -s  /etc/init.d/tf  /etc/rc1.d/K20tf
> ln  -s  /etc/init.d/tf  /etc/rc2.d/S20tf
> ln  -s  /etc/init.d/tf  /etc/rc3.d/S20tf
>  
> I am copying here the wrapper and application logs to explain the 
> problem.   
>  
> >>> I set the log level in wrapper.conf to DEBUG, following is the 
> output of wrapper.log

<snip>