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.
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,
On Thu, Jun 11, 2015 at 5:29 PM, Chao Wang <chaowan@redhat.com> wrote:
Thanks for your reply. Please see in-line below
On 06/11/2015 12:44 AM, Brian Stansberry wrote:
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.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?
That's why I try to seek an better option than current behavior from wildfly.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.2) How does other software solve this problem? If it's solving a valid problem, it seems like there would be a typical solution.[1] https://bugzilla.redhat.com/show_bug.cgi?id=1224170On 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
-- Chao Wang Software Engineer JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
wildfly-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________ wildfly-dev mailing list wildfly-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev
-- James R. Perkins JBoss by Red Hat