geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: [LONG] Re: Startup Scripts - foreground and background
Date Mon, 21 Nov 2005 08:41:35 GMT
This all seems quite reasonable to me.

I will note that I do not like the current output of the progress bar  
startup monitor.  I would prefer that it state how many configurations  
will be started, and then list each configuration together with  its  
startup time, one configuration per line.  I think this would work fine  
both foreground and background.

Thanks,
david jencks

On Nov 20, 2005, at 10:24 PM, John Sisson wrote:

> I am reviewing Dave's startup patches ( GERONIMO-1166 ) and have a  
> couple of ideas for comment.
> [1]. I propose we provide a geronimo.sh file that is modelled on  
> Tomcat's catalina.sh file (  
> http://svn.apache.org/repos/asf/tomcat/container/tc5.5.x/catalina/src/ 
> bin/ ), as a large number of users would already be familiar with its  
> syntax and environment variable naming conventions and it would be  
> good if we had some consistency across Apache products.
> geronimo.sh would support options such as:
>
> jpda start    - Start Geronimo under JPDA debugger
> run             - Start Geronimo in the current window (same as Dave's  
> proposed -foreground)
> start           - Start Geronimo in a separate window (same as Dave's  
> proposed -background)
>
> Also make startup.sh consistent with Tomcat's startup.sh and move the  
> redirection logic and foreground/background logic to geronimo.sh.
>
> If we are consistent with Tomcat it means that if an option isn't  
> passed to geronimo.sh (e.g. start) then usage information will be  
> printed to the terminal. If users invoke startup.sh, it in turn  
> invokes geronimo.sh with the start option (consistent with Tomcat).
>
> I am happy to make these changes if I have no objections.
>
> [2]. File name used for redirected output when using startup.sh  
> -background
>
>    Currently the patch redirects output to a startupProgress.log file.  
> I am thinking the file should be renamed to geronimo.out (consistent  
> with Tomcat's catalina.out) since it may contain more than startup  
> messages over the life of the process.
>
> [3]. Improving format of progress messages in redirected output when  
> using startup.sh -background
>
> For the startup output to not appear garbled in the file that output  
> is redirected to (due to the carriage returns generated by  
> ProgressBarStartupMonitor) we probably need a modified version of  
> ProgressBarStartupMonitor that outputs a line when a configuration is  
> starting/started (without the update thread that updates the line  
> approx every 500ms that the ProgressBarStartupMonitor has).
>
> I initially thought we could use the -quiet option, but that results  
> in no progress being output and it would be nice to be able to look at  
> the geronimo.out file to see what is happening rather than having to  
> look through possibly heaps of messages in the log4j log files.
>
> It would be also be helpful if the output redirected to the  
> geronimo.out file also has the summary of listening ports and started  
> application modules & web applications.
> [4]. Proposed new Geronimo startup options:
>
> -interactive (default)
>        Specify this when output is sent to an interactive  
> terminal/console.  During startup (if -quiet is not specified) the  
> progress message for a configuration will be updated approx every  
> 500ms (using carriage returns to move the cursor on the display to the  
> beginning of the current line to enable the progress message to be  
> updated.  Mutually exclusive with the -noninteractive parameter.
>
> -noninteractive
>        Specify this when output is being redirected to a file or  
> printer.  During startup, a new message (each message on a new line)  
> will be issued during different stages startup. Mutually exclusive  
> with the -interactive parameter.
>
> The above option could also be stored in case in the future we want to  
> enhance shutdown processing to show some progress messages.
>
> The startup.sh script would pass -noninteractive if the process is  
> started in the background.
>
> [5]. New method on StartupMonitor interface
>
> A new method setInteractive(boolean b) could be added to the  
> StartupMonitor interface and invoked by the Daemon class before the  
> systemStarted(kernel) method is called.
>
> Comments?
>
> Thanks,
>
> John
>
> Dave Colasurdo wrote:
>
>> Have attached the patches for both unix (.sh) and windows (.bat)  
>> environments to GERONIMO-1166. Please test them out..
>>
>> Thanks
>> -Dave-
>>
>>
>> Dave Colasurdo wrote:
>>
>>> I've opened a JIRA for this issue and created a patch for the  
>>> windows platform.  Still investigating the unix environment...
>>>
>>>  http://issues.apache.org/jira/browse/GERONIMO-1166
>>>
>>>
>>>
>>> John Sisson wrote:
>>>
>>>> Hi Dave,
>>>>
>>>> I don't think I had any objections to making the startup scripts  
>>>> follow Tomcat as much as possible.  See the following discussions  
>>>> on scripts, I think there were a number of issues discussed that we  
>>>> need to cover:
>>>>
>>>> http://www.mail-archive.com/dev@geronimo.apache.org/msg05926.html
>>>>
>>>> http://www.mail-archive.com/dev@geronimo.apache.org/msg05851.html
>>>>
>>>> http://www.mail-archive.com/dev@geronimo.apache.org/msg06483.html
>>>>
>>>> Regards,
>>>>
>>>> John
>>>>
>>>>
>>>> Dave Colasurdo wrote:
>>>>
>>>>>
>>>>>
>>>>> Jeff Genender wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> Dave Colasurdo wrote:
>>>>>>
>>>>>>> The shutdown scripts are a step forward in usability over  
>>>>>>> manually killing the java process via CTL-C.  While quite  
>>>>>>> simple, CTL-C does not seem very user friendly and should not
be  
>>>>>>> the default mechanism.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> I really don't believe there is a default mechanism, IMHO.  I  
>>>>>> think we are offering multiple ways to do the same thing.  The  
>>>>>> CTRL-C would be heavily used by developers.  The shutdown script
 
>>>>>> could be used by people using a daemon or backgrounding the  
>>>>>> server (which is easily done on both Windows and *nix systems) or
 
>>>>>> a remote server.  The console would/maybe be used by  
>>>>>> mouse-clicking administrators.
>>>>>>
>>>>>> I would surely hope that in a prod environment one is not running
 
>>>>>> the server in a terminal window ;-)
>>>>>>
>>>>>>>
>>>>>>> However, it does seem strange that a user needs to open a new
 
>>>>>>> window to shutdown the server.   Seems like the initial startup
 
>>>>>>> command should return the  command prompt back to the user so
 
>>>>>>> that shutdown can be issued from the same window.  One way to
 
>>>>>>> accomplish this is to have the startup script launch a new  
>>>>>>> window that controls the java process (and output the startup
 
>>>>>>> messages) while the initial prompt is returned to the user. 
 
>>>>>>> This would allow the shutdown to be issued from the initial 

>>>>>>> window.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> For a developer (and me being selfish), running in a terminal  
>>>>>> window is not strange and it seems to be the norm from a command
 
>>>>>> line perspective, rather than the exception.
>>>>>>
>>>>>> IMHO, ss a developer, sending the server into the background is 

>>>>>> not appealing.  I think if one wants control over their terminal,
 
>>>>>> they could issue a startup.sh& (notice the ampersand) to  
>>>>>> background the process. Quite possibly we could also add another
 
>>>>>> script called startup_background.sh (or bat) that could so this 

>>>>>> as well.   We could also create daemon scripts for the different
 
>>>>>> platforms.  Wasn't there a JIRA issue for an NT Service for  
>>>>>> Windows?  We could add init.d scripts for Unix too.
>>>>>>
>>>>>
>>>>> I agree the current behavior is appropriate for a developer.  I  
>>>>> was thinking more about end users. Similar to your suggestion,  
>>>>> should we consider adding an option to the startup.sh|bat script  
>>>>> to put the process in background?  Actually, I'm wondering if the  
>>>>> default behavior (startup.sh|bat w/o any options) should be geared  
>>>>> toward end users and would run the process in background.  And  
>>>>> specifying the option (-foreground) would allow the process to be  
>>>>> run in the current window for developers.
>>>>>
>>>>> Of course, windows service and init.d are also useful.  I think  
>>>>> both proposals are worth pursuing
>>>>>
>>>>> Will look to see if there are current JIRAs open on these..
>>>>>
>>>>>
>>>>>>>
>>>>>>> Also, if we ever support sharing one binary installation that
 
>>>>>>> can start multiple instances of geronimo (each with it's own
 
>>>>>>> unique configuration) then we will also likely need this  
>>>>>>> behavior.
>>>>>>>
>>>>>>> -Dave-
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>


Mime
View raw message