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

That just monitors console output. ​Not exacly, there are various modes of integration, posibly the most

On Jun 12, 2015, at 11:32 AM, Jorge Solórzano <jorsol(a)gmail.com&gt; 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(a)redhat.com&gt; 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/... > > (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(a)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(a)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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > _______________________________________________ wildfly-dev mailing list wildfly-dev(a)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