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