geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From hogstrom <m...@hogstrom.org>
Subject Re: [LONG] Re: Startup Scripts - foreground and background
Date Mon, 21 Nov 2005 14:59:03 GMT
+1 on the ideas John.  You might consider where the server name would go 
when we migrate to multiple configurations.  For instance:

./startup.sh server1 or
./shutdown.sh server1

I wonder where the right place for the PIDs would be?  Probably in a 
$G/var/servers directory so one could map a server name to a PID?  I 
know this is a future item but we're going to get there pretty sooon 
(after the 10th :)

I also like David's idea on the status after initialization that shows 
how long each element took to initialize.

Matt


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