[wildfly-dev] Wildfly start-up as service script depends on console log to determinate start result

Fri Jun 12 18:05:59 EDT 2015

On Fri, Jun 12, 2015 at 1:40 PM, Jason Greene <jason.greene at redhat.com>
wrote:

> We wouldn’t be able to use that approach because its shipped under an
> incompatible viral license (GPL with additional restrictions). Theres also
> the other negative that we try to avoid shipping native bits if at all
> possible.
>
> That a good reason to avoid that...

And what about Commons Daemon?, it stills depends on the native part, but
wildfly already includes native binaries for windows, a separate download
of the native part could be an option for both unix and windows...

> On Jun 12, 2015, at 12:02 PM, Jorge Solórzano <jorsol at gmail.com> wrote:
>
>
> On Fri, Jun 12, 2015 at 10:51 AM, Jason Greene <jason.greene at redhat.com>
> wrote:
>
>> That just monitors console output.
>>
>> Not exacly, there are various modes of integration, posibly the most
> complex but flexible aproach is to use a listener[1] so it can be adapted
> properly to what we want.
>
> [1] http://wrapper.tanukisoftware.com/doc/english/integrate-listener.html
>
>
>
>
>> On Jun 12, 2015, at 11:32 AM, Jorge Solórzano <jorsol at gmail.com> wrote:
>>
>> It has been considered the use of Java Service Wrapper[1]? it depends on
>> native binaries but almost all platforms are supported.
>>
>> [1] http://wrapper.tanukisoftware.com
>>
>>
>> Jorge Solórzano
>> http://www.jorsol.com
>>
>> On Fri, Jun 12, 2015 at 8:27 AM, Brian Stansberry <
>> brian.stansberry at redhat.com> wrote:
>>
>>> How does EAP 5 deal with this? IIRC disabling console logging is not
>>> something new in EAP 6.
>>>
>>> On 6/11/15 6:29 PM, Chao Wang wrote:
>>> > Thanks for your reply. Please see in-line below
>>> >
>>> > On 06/11/2015 12:44 AM, Brian Stansberry wrote:
>>> >> A couple thoughts:
>>> >>
>>> >> 1) Looking at wildfly-init-redhat.sh at least, I don't see how that
>>> >> check is actually testing for successful startup. It looks like it's
>>> >> just trying to delay start() returning for a while, max 30 secs.
>>> >>
>>> >> So, what purpose is this fulfilling?
>>> > My bad about issue background. It's actually an case in EAP 6 (not yet
>>> > in wildfly). EAP 6.x script has launched state like:
>>> >
>>> https://github.com/jbossas/jboss-eap/blob/6.4.x/build/src/main/resources/bin/init.d/jboss-as-standalone.sh#L110
>>> > (not in wildfly's script). Also, console log handler has been removed
>>> > only in EAP full-ha mode long time ago due to performance
>>> > concern.(wildfly keeps it for the moment). This leads to issue in
>>> > bz1224170 <https://bugzilla.redhat.com/show_bug.cgi?id=1224170>.
>>> > That's why I try to seek an better option than current behavior from
>>> > wildfly.
>>> >>
>>> >> 2) How does other software solve this problem? If it's solving a valid
>>> >> problem, it seems like there would be a typical solution.
>>> > I have checked some other application servers, most of them let users
>>> > themselves to write a script to run as service for their OS. Geronimo
>>> > does provide a script, Although I did damage to its configuration file
>>> > to make a fatal error, terminal output still displays "Server started".
>>> > In fact, process does not event exist and detail error can be seen in
>>> > log file.
>>> >> On 6/9/15 8:59 AM, Chao Wang wrote:
>>> >>> Hi all,
>>> >>>
>>> >>> The Wildfly start-up as service scripts wildfly-init-redhat.sh and
>>> >>> wildfly-init-debian.sh currently depend on a grep action of key
>>> message
>>> >>> 'WFLYSRV0025:' in console log to determinate whether service start is
>>> >>> successful. The log message indication is accurate, however, it's not
>>> >>> that robust since user can always remove console handler from logging
>>> >>> subsystem. I have opened a WFCORE enhancement jira
>>> >>> https://issues.jboss.org/browse/WFCORE-747  for it.
>>> >>>
>>> >>> For the moment, I have tried three options, they're all not that
>>> perfect
>>> >>> to implement
>>> >>>
>>> >>> 1. Stay with exact log message, users need to define their jboss log
>>> >>> directory such as $JBOSS_HOME/standalone/log/server.log for
>>> standalone
>>> >>> and $JBOSS_HOME/domain/log/host-controller.log for domain instead of
>>> >>> searching in console log. This is more like another workaround since
>>> it
>>> >>> is also volatile once we update log message in future release.(EAP
>>> has
>>> >>> 'JBAS015874:')
>>> >>>
>>> >>> 2. Use service pid, this is not precise because a long start-up can
>>> >>> crash in the last second. It needs to wait a suitable seconds before
>>> >>> checking pid existence. and still it can not avoid fake success in
>>> rare
>>> >>> case just before timeout.
>>> >>>
>>> >>> 3. Use read-attribute server-state through CLI connection as I did in
>>> >>> Pull Request on Jira. This is declined as it is possible that
>>> >>> authentication is required before connection. In such case, any  non
>>> >>> encrypted password is not advised in configuration files.
>>> >>>
>>> >>> Therefore, I would like to listen for your opinions for them. Any
>>> other
>>> >>> suggestion is certainly welcomed in mail or on jira.
>>> >>>
>>> >>> Best regards,
>>> >>>
>>> >>> Chao
>>> >>>
>>> >>>
>>> >>> _______________________________________________
>>> >>> wildfly-dev mailing list
>>> >>> wildfly-dev at lists.jboss.org
>>> >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>> >>>
>>> >>
>>> >
>>> > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1224170
>>> >
>>> > --
>>> > Chao Wang
>>> > Software Engineer
>>> > JBoss by Red Hat
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > wildfly-dev mailing list
>>> > wildfly-dev at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>> >
>>>
>>>
>>> --
>>> Brian Stansberry
>>> Senior Principal Software Engineer
>>> JBoss by Red Hat
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>> --
>> Jason T. Greene
>> WildFly Lead / JBoss EAP Platform Architect
>> JBoss, a division of Red Hat
>>
>>
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150612/df1ed160/attachment-0001.html 