geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sachin Patel <sppat...@gmail.com>
Subject Re: [LONG] Re: Startup Scripts - foreground and background
Date Mon, 21 Nov 2005 15:09:07 GMT
and after startup we could could log/output the list of configurations 
that failed to start.

Sachin Patel wrote:
> One immediate concern I have is the server shutting down whenever any 
> configuration fails to start.  This is ok for criticial system 
> configurations, but do we want the same behavior for user apps? Do we 
> want to consider a temporary solution for now to possibly include a 
> "--force" parameter that continues starting the server after a failure?
>
> Sachin
>
> hogstrom wrote:
>> +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