Hey guys, just heads up, I've managed to prepare[1] all powershell scripts to replace the aging .bat ones. New scripts unify most of the shared "code" that all scripts use by including common.ps1, and each script only has the code that differs from common behavior they all share. As result of move we now have much more reliable and faster scripts that share common code, which helps with maintaining a lot. New scripts (domain.ps1 & standalone.ps1) now support --background (also controllable via .conf.ps1) option that runs the process in background and remembers its pid and as such add support for feature that until now was only in *nix version of scripts. I would like to propose this PR for inclusion to WildFly 10. As it doesn't alter any existing behavior but just adds & improve the script experience on Windows. As we get to test and verify that new scripts don't break/include any currently available option/action I would also like to remove the batch scripts[2], so they would just do call out to their .ps1 counter parts. Once this scripts get merged, I will send PR to also add PS scripts for WildFly full defined scripts, given that most of the functionally is already in "common.ps1" new scripts will be just simple 5 liners [3] -- tomaz [1] https://github.com/wildfly/wildfly-core/pull/1118 [2] https://github.com/wildfly/wildfly-core/pull/1126 [3] https://github.com/ctomc/wildfly-core/blob/powershell/core-feature-pack/s... _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

Hum, it will break my NetBeans plugin as I rely on the shell scripts ;) I can easily fix this but I vote against removing the bat files this late in the release process.

On 29 Sep 2015, at 18:08, Emmanuel Hugonnet wrote: > Hum, it will break my NetBeans plugin as I rely on the shell scripts ;) interesting - all my attempts on using the shell scripts ended with misery since they resulted in not being able to reliably stop/start the server since we don't get the chance to signal the process to die/stop. Any info on how you worked around that in Netbeans ? /max > I can easily fix this but I vote against removing the bat files this late in the release process. > My 2 cents > Emmanuel > > > Le 29/09/2015 17:48, Brian Stansberry a écrit : >> Thanks for posting this. >> >> I'm curious if anyone on the list has concerns about the .bat scripts >> now delegating the powershell ones. The advantages are obvious; the >> disadvantages I really don't know. >> >> I only occasionally use Windows in a VM, so I haven't really kept up >> with what is supported in what versions of Windows. I know Powershell >> has been around a long, long time. >> >> On 9/29/15 10:29 AM, Tomaž Cerar wrote: >>> Hey guys, >>> >>> >>> just heads up, I've managed to prepare[1] all powershell scripts to >>> replace the aging .bat ones. >>> >>> New scripts unify most of the shared "code" that all scripts use by >>> including common.ps1, >>> and each script only has the code that differs from common behavior they >>> all share. >>> >>> As result of move we now have much more reliable and faster scripts that >>> share common code, >>> which helps with maintaining a lot. >>> >>> New scripts (domain.ps1 & standalone.ps1) now support --background (also >>> controllable via .conf.ps1) >>> option that runs the process in background and remembers its pid and as >>> such add support for >>> feature that until now was only in *nix version of scripts. >>> >>> I would like to propose this PR for inclusion to WildFly 10. As it >>> doesn't alter any existing behavior >>> but just adds & improve the script experience on Windows. >>> >>> As we get to test and verify that new scripts don't break/include any >>> currently available option/action >>> I would also like to remove the batch scripts[2], so they would just do >>> call out to their .ps1 counter parts. >>> >>> Once this scripts get merged, I will send PR to also add PS scripts for >>> WildFly full defined scripts, >>> given that most of the functionally is already in "common.ps1" new >>> scripts will be just simple 5 liners [3] >>> >>> >>> -- >>> tomaz >>> >>> >>> [1] https://github.com/wildfly/wildfly-core/pull/1118 >>> [2] https://github.com/wildfly/wildfly-core/pull/1126 >>> [3] >>> https://github.com/ctomc/wildfly-core/blob/powershell/core-feature-pack/s... >>> >>> >>> >>> _______________________________________________ >>> 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 /max http://about.me/maxandersen

On Wed, Sep 30, 2015 at 1:38 PM, Emmanuel Hugonnet <ehugonne(a)redhat.com <mailto:ehugonne@redhat.com>> wrote: To stop the process : first I try the management API command then I have some funky code from arquillian (iirc) which kills the jboss-modules processes. you probably mean https://github.com/wildfly/wildfly-arquillian/blob/master/protocol-jmx/sr... Great thing it works for you :) This was written by Stuart & me over some discussion in Brno F2F as an optional feature that we would use in testsuite for our CI as we had problems with hanging processes. But it ended up not really useful... -- tomaz

okey, so that explain why you like the scripts - these issues manifests itself most on windows ;) so how do you handle running two servers ? it kills all of them ? got a link to the exact code you use ?

Hey guys, just heads up, I've managed to prepare[1] all powershell scripts to replace the aging .bat ones. New scripts unify most of the shared "code" that all scripts use by including common.ps1, and each script only has the code that differs from common behavior they all share. As result of move we now have much more reliable and faster scripts that share common code, which helps with maintaining a lot. New scripts (domain.ps1 & standalone.ps1) now support --background (also controllable via .conf.ps1) option that runs the process in background and remembers its pid and as such add support for feature that until now was only in *nix version of scripts. I would like to propose this PR for inclusion to WildFly 10. As it doesn't alter any existing behavior but just adds & improve the script experience on Windows. As we get to test and verify that new scripts don't break/include any currently available option/action I would also like to remove the batch scripts[2], so they would just do call out to their .ps1 counter parts. Once this scripts get merged, I will send PR to also add PS scripts for WildFly full defined scripts, given that most of the functionally is already in "common.ps1" new scripts will be just simple 5 liners [3] -- tomaz [1] https://github.com/wildfly/wildfly-core/pull/1118 [2] https://github.com/wildfly/wildfly-core/pull/1126 [3] https://github.com/ctomc/wildfly-core/blob/powershell/core-feature-pack/s... _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

On Tue, Sep 29, 2015 at 10:37 PM, James Perkins <jperkins(a)redhat.com&gt; wrote: > > > The one concern I do have is with the --background bit. We do create a PID file for the LAUNCH_IN_BACKGROUND, but it doesn't make sense to me why we do. That's off topic for this though :) We don't seem to use these files for anything so I just don't see the point in creating them. > > Anyway, the whole PID thing I think needs to be thought about. With the current behavior in the bash scripts it doesn't exit until the background process has been stopped. I can't really tell what the PS scripts do with the launch in background. Does the script exit or pause until the process is exited? the LAUNCH_IN_BACKGROUND & --background do the same thing, only difference is that one is command line parameter other is in the config file. We use pid file to check if the process is already running and complain if is instead of starting the server directly. Powershell script does exit after background process is started, which feels like proper behavior.

The current behavior in bash scripts looks bit erratic as Rosta figured out today that .sh script doesn't exit after it is running in background, confusing/strangely behaving part of is related to cleaning up the pid file, which is done bit differently in ps scripts...

But anyhow, lets discuss details on hipchat, Tomaz

Right this is my concern. The behavior is different as the bash scripts don't exit. They wait for the process to end. Maybe it's correct to be different, I don't know.

Yeah, it looks like that LAUNCH_IN_BACKGROUND behavior is pretty much implemented to satisfy the init.d script we have and is not really useful if you run it directly.

If that is really so, I am not a fan of having that in standalone.sh directly...

On 10/1/15 7:17 AM, Rostislav Svoboda wrote: >> Right this is my concern. The behavior is different as the bash >> scripts don't exit. They wait for the process to end. Maybe it's >> correct to be different, I don't know. > > If you send signal 10 (kill -l 10 returns USR1) AS got restarted thanks > while loop - > https://github.com/wildfly/wildfly-core/blob/master/core-feature-pack/src... > and it doesn't matter if you execute it normally or with > LAUNCH_JBOSS_IN_BACKGROUND > > don't know what the real use case is to get it restarted I'm not certain if you were asking ^^^ in general or just in the context of these init scripts. The answer in general is this is what allows the

:shutdown(restart=true) management operation to work; the restart=true causes the process to exit with exit code 10. This relies on the launch script understanding this exit code and starting a new process. > wildfly-init-redhat.sh and wildfly-init-debian.sh do restart by stop&&start > restart) > $0 stop > $0 start > EAP 6.4.3 RPM init.d script does stop&&start too > restart|reload) > stop > sleep 3 > start > RETVAL=$? > ;; > > There is some magic in the .sh scripts with number 128 and it's related > wait command / bash / signals > http://tldp.org/LDP/Bash-Beginners-Guide/html/sect_12_02.html#sect_12_02_02 > http://veithen.github.io/2014/11/16/sigterm-propagation.html > >> >> Yeah, it looks like that LAUNCH_IN_BACKGROUND behavior is pretty much >> implemented >> to satisfy the init.d script we have and is not really useful if you run >> it >> directly. > > it is used in: > https://github.com/wildfly/wildfly-core/blob/master/core-feature-pack/src... > https://github.com/wildfly/wildfly-core/blob/master/core-feature-pack/src... > > read kpid < $JBOSS_PIDFILE in stop function > >> If that is really so, I am not a fan of having that in standalone.sh >> directly... >> > > domain.sh has the same mechanism LAUNCH_JBOSS_IN_BACKGROUND + JBOSS_PIDFILE > If it's removed from both files something will have to be added to the > init/systemd scripts. > > Cheers. > Rostislav > _______________________________________________ > 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