No terminate task in build gradle

In the moqui-framework build.gradle file, there are various tasks we can execute such as run, load, clean,etc.

I couldn’t find any task to stop/terminate Moqui, like we have terminateOfbiz in OFBiz.

While running Moqui using docker, if any changes are done in configuration file, we need to restart the container, if we could terminate or restart Moqui from inside the container it would be very useful.

I was wondering if there is any specific reason why we don’t have a stop/terminate gradle task in Moqui.

1 Like

terminateOfbiz (I am the author of it BTW) is to force OFBiz termination in case something goes wrong OR in case it’s running as a background job ofbizBackground. This is not equivalent in moqui. In case of production environment you simply deploy to docker, and in dev environments you simply call run, and Ctrl-C would suffice in killing in the instance


We added a button in the System Dashboard:


    <transition name="systemExit">
        <default-response url="."/>
<link url="systemExit" text="Shut Down Server" confirmation="This will shut the server down immediately."/>

What is the use case for this? I’m wondering what you’re deployment looks like just for future reference.

I can’t speak for Ayan, but against an IBM iSeries, there are issues running the WAR file with payroll and Websphere…to the extent it can’t complete some processes.

As such, we have multiple instances running concurrently against several payroll companies that are all running on the embedded Jetty server.

The Unix-y side of the iSeries has no “screen” type option for recovering a backgrounded job where you had signed off or lost your connection to.

Anyway, the button for shutdown was the only clean way to shut down a selected instance (or even just a single instance). It does shut down cleanly with a System.exit(0).


I do lot of POCs around framework capability and deployment, mostly working in docker container. Did not feel the need of terminate task in any production use case. But while making changes in the container it would be easier If I could just restart Moqui and not the whole container after making changes in configuration.
It just add more steps, exit the container, restart it and bash in it again. Will be easier to just restart Moqui from inside the container and save some manual effort.
I was just wondering if there was some specific reason to not have a terminate task, so I asked.

Thanks for the info

1 Like

I have also added a page that includes a ‘System.exit(0)’ shutdown and a clear cache button. This page allows for the uploading of a tar.gz file containing files modified since the last deployment (based on a git tag). After the upload, it will extract the files to the relevant component. If only the screen or services have changed, I can choose to clear the cache. If a restart of Moqui is necessary, I click shutdown. Since it’s in a Docker container, this action will simply restart the container.


This is interesting. Why create this feature instead of building and deploying a new docker container with the changes?

Some of my applications run only in a single instance, so I don’t need an image to start multiple instances. These apps run in a managed environment. I can only connect via VPN to a jump machine and then SSH into the server, which does not have internet access. Therefore, it is not easy to fetch dependencies and build on the server. However, these servers do expose an HTTP port to the internet. So, I use a JDK Docker container and mount the Moqui runtime into it. Uploading files and terminating the process is a far easier method to roll out updates. Creating an image and transferring it to the server would be inconvenient.

1 Like

The absence of a specific stop or terminate Gradle task in Moqui’s build gradle file may be due to its design philosophy, which may prioritize flexibility and compatibility with various deployment methods. Handling Moqui’s lifecycle, such as stopping or restarting it, is typically managed through external tools like Docker commands or container orchestration tools in scenarios where Moqui is run within containers. This approach allows users to integrate Moqui seamlessly into their existing deployment workflows while providing flexibility in managing its lifecycle.

1 Like

Thanks @eric_shane That’s probably right. It’s best not to run Moqui in a Gradle task in production. Instead using docker, docker compose, or k8s would be the way to go.

1 Like