We use commandbox server with a custom docker image with docker-compose.
The docker-compose stop command it seems that doesn’t stop the server cleanly. The next execution of the docker exit with the error:
devel-lucee5-1 | ERROR (5.5.2+00578)
devel-lucee5-1 |
devel-lucee5-1 | Cannot start server [app] because it is already running.
devel-lucee5-1 |
devel-lucee5-1 | Run [server info --verbose] to find out why CommandBox thinks this server is running.
devel-lucee5-1 |
devel-lucee5-1 exited with code 1
The next execution works as expected:
devel-lucee5-1 | [INFO ] runwar.server: Server is up - http-port:8080
Commandbox version 5.5.2
Hi @David_Sedeno I know what change is affecting you, but I’m not entirely sure why it’s affecting you. CommandBox 5.5 changed from a port-binding method of telling if the server was running to a PID file that’s written when the server starts and then removed automatically by a JVM shutdown hook. It seemed pretty foolproof in our testing, but once we released CommandBox 5.5, our users revealed a number of ways you can apparently shutdown java and NOT have the shutdown hooks fire (i.e., the PID file gets left on disk!)
If the JVM doesn’t shut down clean, the next time you check the status, it will appear as though the server is running. There is an asynchronous (for performance) check of the actual PID inside the file that deletes the file if that PID is not actually running, but that will only affect the next time you check the status.
The bleeding edge of CommandBox right now just does the actual PID check synchronously because of how much trouble this caused, but am curious why your containers are not shutting down cleanly. CommandBox itself will properly wait for the server JVM to shutdown when the start --console command gets interrupted. The default docker stop command sends a SIGTERM, which the box binary will intercept and then interrupt the main thread, waiting 10 seconds for it to complete. I just did this quick test locally with docker and the container started fine on the second attempt:
docker pull ortussolutions/commandbox
docker run --name test -it ortussolutions/commandbox
# Ctrl-C to stop the container
docker start -ia test
So however you’re shutting down your containers must be murdering the JVM before it can shut down cleanly, and leaving the PID file on disk.
So, as far as a “fix”-- You can update your custom images to use the CommandBox bleeding edge build which more aggressively tests the PID file. you could delete the PID file manually (it’s located inside the server home)
rm -f `box server info property=pidfile`
Or you can just add a status check prior to starting, which will kick off the async check that removes the file if it’s invalid which will allow it to work the “next” time.
box server status
Thanks Brad!
as always excellent explanation of the problem and the fixes.
In our case simply with the rm -f of the pid file before the start of the server.
Thanks!
1 Like