Startup Scripts - foreground and background

[Dave Colasurdo <da...@earthlink.net>]

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-
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
> 
> 

Re: [LONG] Re: Startup Scripts - foreground and background

[Dain Sundstrom <da...@iq80.com>]

+1 to John's proposal

I think it would be nice to have "each configuration together with   
its startup time, one configuration per line" noted in the log  
geronimo.out file if possible.

-dain

On Nov 21, 2005, at 2:41 AM, David Jencks wrote:

> 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-
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>

Re: [LONG] Re: Startup Scripts - foreground and background

[Aaron Mulder <am...@alumni.princeton.edu>]

Regarding -interactive and -noninteractive and David J not liking the output...

I think the better way to do it is to implement a StartupMonitor that
behaves the way you want it to, and then have a single flag to use
that instead of the ProgressBarStartupMonitor (just like now we have a
flag to switch between the silent one and the progress bar).  So there
would not be a "-interactive" flag or a setInteractive method on the
StartupMonitor interface.  There could instead be a "-noninteractive"
flag (though perhaps with a shorter name) that would switch to use a
new StaticStartupMonitor or whatever instead.

Thanks,
    Aaron

On 11/21/05, David Jencks <da...@yahoo.com> wrote:
> 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-
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>>
> >>
> >
>
>

Re: [LONG] Re: Startup Scripts - foreground and background

[David Jencks <da...@yahoo.com>]

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-
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>

Re: [LONG] Re: Startup Scripts - foreground and background

[Sachin Patel <sp...@gmail.com>]

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-
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>
>

Re: [LONG] Re: Startup Scripts - foreground and background

[Sachin Patel <sp...@gmail.com>]

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-
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>>
>>
>
>
>

Re: [LONG] Re: Startup Scripts - foreground and background

[hogstrom <ma...@hogstrom.org>]

+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-
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>
>
>
>

Re: [LONG] Re: Startup Scripts - foreground and background

[Bruce Snyder <br...@gmail.com>]

On 11/20/05, John Sisson <jr...@gmail.com> 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.

These are all very good ideas, John. I really like the idea to model
our scripts after Tomcat's scripts. Surfing off of users potential
familiarity with the Tomcat scripts is an awesome idea. This should
help to break down some barriers for users immediately.

Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'

The Castor Project
http://www.castor.org/

Apache Geronimo
http://geronimo.apache.org/

Re: [LONG] Re: Startup Scripts - foreground and background

[Dave Colasurdo <da...@earthlink.net>]

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)
> 
No major objections.  Though I don't think "run" and "start" are real 
intuitive to the user.  The unix environment does start a background 
process.


> Also make startup.sh consistent with Tomcat's startup.sh and move the 
> redirection logic and foreground/background logic to geronimo.sh.
> 
+1

> 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.
> 
Can you explain the relationship of the startup log to the other log 
files.  I thought there were other log files that captured all of logged 
  runtime events and this log (startupProgress.log) would be used 
primarily for startup status.

Also, be aware that the current patches are deleting the old log 
(currently startupProgress.log) during startup.


> [3]. Improving format of progress messages in redirected output when 
> using startup.sh -background
> 
yep.. this definitely needs to be addressed.

> 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.
>
The current default for startup.sh is a background (start) session.  I 
assume this should also default to noninteractive output.  And when 
foreground  (run) is specified  sessions should default to interactive.

I guess there will be cases when the behavior will be overridden with 
the new interactive/non-interactive keywords though expect most users 
will use the setting associated with foreground/background for unix 
systems.

> -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 for following up and enhancing these patches!

> 
> 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-
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
> 
> 
> 

RE: [LONG] Re: Startup Scripts - foreground and background

[Jeff Genender <jg...@savoirtech.com>]

+1 on this idea.  I would really like to see this stuff in the scripts.

Jeff

> -----Original Message-----
> From: John Sisson [mailto:jrsisson@gmail.com] 
> Sent: Sunday, November 20, 2005 11:24 PM
> To: dev@geronimo.apache.org
> Subject: [LONG] Re: Startup Scripts - foreground and background
> 
> 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/catal
> ina/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-
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >>
> >>
> >
> 

[LONG] Re: Startup Scripts - foreground and background

[John Sisson <jr...@gmail.com>]

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-
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>