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

Fri Jun 12 14:11:29 EDT 2015

On Fri, Jun 12, 2015 at 11:32 AM, James R. Perkins <jperkins at redhat.com>
wrote:

>  This won't work as there's no guarantee there will be a server.log and/or
> that it would live in log directory. The best solution involves not reading
> logs at all. I don't have any great ideas on the best way to currently do
> that.
>
>
> James, that why in step 5 i mention 2 aproach, if timeout return a
warning, or if timeout check if pid is still up and return ok. It's not
perfect since it return control until timeout, but it's more reliable that
depend on console output.

> On 06/11/2015 10:25 PM, Jorge Solórzano wrote:
>
>  I think there is no easy fix, we can assume for example that after 3
> seconds that the PID exists then the process is up and return OK, but if
> the process stops latter, it will be a fake start.
>
>  I know that we should not rely on read the log as James stated, but
> until we can figure out a better aproach this is my proposal, I can modify
> wildfly-init-debian.sh to have this behavior
>
>  1. Add to logging subsystem to standalone*.xml:
>             <logger category="org.jboss.as">
>                 <level name="INFO"/>
>             </logger>
>
>  2. Remove JBOSS_CONSOLE_LOG and read JBOSS_LOG_DIR
>
>  3. If standalone read "$JBOSS_LOG_DIR/server.log"
>  if domain read "$JBOSS_LOG_DIR/host-controller.log"
>  to find WFLYSRV0025 or the string used for EAP... this is probably
> volatile but it's not changed frequently, in fact it has been changed only
> once.
>
>  4. Always check the status of pid (if dies return immediately).
>
>  5. If server.log is not found, deactivated or not print the correct
> output there are two choices:
>  a. On wait timeout, send a warning about an unknow status (this is how
> works right now).
>  b. On wait timeout, just check if PID is still up and return OK,
> otherwise FAILURE.
>
>  I believe this approach avoids the problem of console log...
>
>  
> 
> Best regards,
>
>
> Jorge Solórzano
> http://www.jorsol.com
>
> On Thu, Jun 11, 2015 at 5:29 PM, Chao Wang <chaowan at redhat.com> 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 jirahttps://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 listwildfly-dev at lists.jboss.orghttps://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
>>
>
>
>
> _______________________________________________
> wildfly-dev mailing listwildfly-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
> --
> James R. Perkins
> JBoss by Red Hat
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150612/864c0c53/attachment-0001.html 