<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif;display:inline">​</div><br><div class="gmail_extra"><div class="gmail_quote">On Fri, Jun 12, 2015 at 11:32 AM, James R. Perkins <span dir="ltr">&lt;<a href="mailto:jperkins@redhat.com" target="_blank">jperkins@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    This won&#39;t work as there&#39;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&#39;t have any great ideas on
    the best way to currently do that.<div><div class="h5"><br>
    <br></div></div></div></blockquote><div><div class="gmail_default" style="font-family:verdana,sans-serif;display:inline">​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&#39;s not 
perfect since it return control until timeout, but it&#39;s more reliable 
that depend on console output.<br></div></div><br><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div><div class="h5">
    <div>On 06/11/2015 10:25 PM, Jorge Solórzano
      wrote:<br>
    </div>
    <blockquote type="cite">
      <div dir="ltr">
        <div style="font-family:verdana,sans-serif">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.<br>
          <br>
        </div>
        <div style="font-family:verdana,sans-serif">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<br>
          <br>
        </div>
        <div style="font-family:verdana,sans-serif">1. Add to logging
          subsystem to standalone*.xml:<br>
                      &lt;logger category=&quot;<a href="http://org.jboss.as" target="_blank">org.jboss.as</a>&quot;&gt;<br>
                          &lt;level name=&quot;INFO&quot;/&gt;<br>
                      &lt;/logger&gt;<br>
          <br>
        </div>
        <div style="font-family:verdana,sans-serif">2. Remove
          JBOSS_CONSOLE_LOG and read JBOSS_LOG_DIR<br>
          <br>
        </div>
        <div style="font-family:verdana,sans-serif">3. If standalone read
          &quot;$JBOSS_LOG_DIR/server.log&quot;<br>
           if domain read &quot;$JBOSS_LOG_DIR/host-controller.log&quot;<br>
        </div>
        <div style="font-family:verdana,sans-serif">to find <span><span></span>WFLYSRV0025
            or the string used for EAP... this is probably volatile but
            it&#39;s not changed frequently, in fact it has been changed
            only once.<br>
            <br>
          </span></div>
        <div style="font-family:verdana,sans-serif"><span>4. Always check
            the status of pid (if dies return immediately).<br>
            <br>
          </span></div>
        <div style="font-family:verdana,sans-serif"><span>5. If server.log
            is not found, deactivated or not print the correct output
            there are two choices:<br>
          </span></div>
        <div style="font-family:verdana,sans-serif"><span>a. On wait
            timeout, send a warning about an unknow status (this is how
            works right now).<br>
          </span></div>
        <div style="font-family:verdana,sans-serif"><span>b. On wait
            timeout, just check if PID is still up and return OK,
            otherwise FAILURE.<br>
          </span></div>
        <div style="font-family:verdana,sans-serif"><span><br>
          </span></div>
        <div style="font-family:verdana,sans-serif">I believe this approach
          avoids the problem of console log...<br>
        </div>
        <div style="font-family:verdana,sans-serif"><br>
        </div>
        <div class="gmail_extra">
          <div style="font-family:verdana,sans-serif">​
            <div style="font-family:verdana,sans-serif;display:inline">​</div>
            Best regards,<br>
          </div>
          <br clear="all">
          <div>
            <div><br>
              Jorge Solórzano<br>
              <a href="http://www.jorsol.com" target="_blank">http://www.jorsol.com</a></div>
          </div>
          <br>
          <div class="gmail_quote">On Thu, Jun 11, 2015 at 5:29 PM, Chao
            Wang <span dir="ltr">&lt;<a href="mailto:chaowan@redhat.com" target="_blank">chaowan@redhat.com</a>&gt;</span>
            wrote:<br>
            <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
              <div bgcolor="#FFFFFF" text="#000000">
                <div>Thanks for your reply. Please see in-line below<span><br>
                    <br>
                    On 06/11/2015 12:44 AM, Brian Stansberry wrote:<br>
                  </span></div>
                <span>
                  <blockquote type="cite">
                    <pre>A couple thoughts:

1) Looking at wildfly-init-redhat.sh at least, I don&#39;t see how that 
check is actually testing for successful startup. It looks like it&#39;s 
just trying to delay start() returning for a while, max 30 secs.

So, what purpose is this fulfilling?</pre>
                  </blockquote>
                </span> My bad about issue background. It&#39;s actually an
                case in EAP 6 (not yet in wildfly). EAP 6.x script has
                launched state like: <a href="https://github.com/jbossas/jboss-eap/blob/6.4.x/build/src/main/resources/bin/init.d/jboss-as-standalone.sh#L110" target="_blank">https://github.com/jbossas/jboss-eap/blob/6.4.x/build/src/main/resources/bin/init.d/jboss-as-standalone.sh#L110</a>
                (not in wildfly&#39;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 <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1224170" target="_blank">bz1224170</a>. <br>
                That&#39;s why I try to seek an better option than current
                behavior from wildfly. <span>
                  <blockquote type="cite">
                    <pre>2) How does other software solve this problem? If it&#39;s solving a valid 
problem, it seems like there would be a typical solution.</pre>
                  </blockquote>
                </span> 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
                &quot;Server started&quot;. In fact, process does not event exist
                and detail error can be seen in log file.
                <div>
                  <div>
                    <blockquote type="cite">
                      <pre>On 6/9/15 8:59 AM, Chao Wang wrote:
</pre>
                      <blockquote type="cite">
                        <pre>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
&#39;WFLYSRV0025:&#39; in console log to determinate whether service start is
successful. The log message indication is accurate, however, it&#39;s not
that robust since user can always remove console handler from logging
subsystem. I have opened a WFCORE enhancement jira
<a href="https://issues.jboss.org/browse/WFCORE-747" target="_blank">https://issues.jboss.org/browse/WFCORE-747</a> for it.

For the moment, I have tried three options, they&#39;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
&#39;JBAS015874:&#39;)

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.
<div style="font-family:verdana,sans-serif;display:inline">​​</div>
Best regards,

Chao


_______________________________________________
wildfly-dev mailing list
<a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a>
<a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a>

</pre>
                      </blockquote>
                    </blockquote>
                    <br>
                  </div>
                </div>
                [1] <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1224170" target="_blank">https://bugzilla.redhat.com/show_bug.cgi?id=1224170</a><span><font color="#888888"><br>
                    <pre cols="72">-- 
Chao Wang
Software Engineer
JBoss by Red Hat</pre>
                  </font></span></div>
              <br>
              _______________________________________________<br>
              wildfly-dev mailing list<br>
              <a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a><br>
              <a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
            </blockquote>
          </div>
          <br>
        </div>
      </div>
      <br>
      <fieldset></fieldset>
      <br>
      <pre>_______________________________________________
wildfly-dev mailing list
<a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a>
<a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a></pre>
    </blockquote>
    <br>
    </div></div><span class=""><font color="#888888"><pre cols="72">-- 
James R. Perkins
JBoss by Red Hat</pre>
  </font></span></div>

</blockquote></div><br></div></div>