Proposal to merge my lucee_ctl improvements

language proposals
1

I made a bunch of improvements to lucee_ctl which I’ve been running in production for more than a year, and I’m sure everyone would benefit from this enhanced version.

@Zackster let me know if it’s okay for me to submit a pull request?

lucee_ctl changelog

2025-08-03

  1. Performance optimizations: restart is faster because it doesn’t arbitrarily wait 5 seconds when the server may have stopped much quicker than that; startup confirmation exits immediately upon success instead of waiting fixed time; stop is faster due to refactoring of redundant findpid calls; proactive stale PID cleanup prevents unnecessary process check.

  2. Replaced findpid() with the more semantically correct checkisrunning(), which first deletes stale PID file from server reboot.

  3. start() function now confirms whether the server is running (with 10 second timeout) and provides proper success/failure feedback instead of just assuming it worked.

  4. stop() function now waits for graceful shutdown and provides better timeout messaging when forcing a kill.

  5. status() function enhanced to show not just the PID but also “has been running since” datetime.

  6. Added a proper restart() function that waits for confirmation of shutdown before starting again, replacing the old “stop, sleep 5, start” approach.

  7. Improved error handling and user feedback throughout with more descriptive messages and exit status checking.

  8. Removed support for environments that don’t have JRE installed because it is bundled with Lucee installer. That resulted in removal of substitution patterns @@luceeJREhome@@ and @@luceeJAVAhome@@ in lucee.xml which means change_user.sh can be tested independently of building the installer.

  9. Removed support for OpenBD while remaining backward compatible with legacy automated workflows as long as the engine argument is set to “lucee”.

  10. Refactored if statements to use [[ … ]] (bash conditional) instead of [ … ] (POSIX) and double quotes around variables to prevent word splitting and globbing.

  11. Improved Usage statement by removing brackets around username argument because it is not optional.

  12. Changed rm -rf to rm -f because -r (recursive) applies only to directories.

4 Likes
2

Always welcome, I need to get the GitHub actions working on PRs, do they work on your fork?

Get rid of the openbd stuff

The no jre version could also skip overriding the env variables altogether

It’s so great having you jumping in and contributing

1 Like
3

For my fork the GitHub build fails every time on publish-to-s3, but oddly all the other tests pass.

image
image2515×2059 365 KB

4

Yeah it needs a check to see if s3 credentials are defined

5

I just submitted my PR woohoo!

And in my original post I updated the changelog.

:partying_face:

2 Likes
6

I came to realize the significance of the lucee.xml edit’s beneficial impact for testing change_user.sh!

  1. Removed support for environments that don’t have JRE installed because it is bundled with Lucee installer. That resulted in removal of substitution patterns @@luceeJREhome@@ and @@luceeJAVAhome@@ in lucee.xml which means change_user.sh can be tested independently of building the installer.
1 Like
7

Reverting functionality to make testing easier? Yeah nah, no go.

Being able to just the system JRE is way more useful and important than allowing some testing of script which gets changed once in a blue moon

plus your changes also broke the windows service.bat

I’ve done some improvements to the CI, it should no run on pull requests, it tests the service.bat for windows and it should bail on the publish to s3 when no creds are set or dry_run is true.

Try rebasing your branch?

8

Sorry, I misinterpreted your previous directive.

I thought you were telling me to remove it.

9

no worries

so I believe previously it hardwired the paths to the detected system jre, that could be left to just pick up the currently system config

10

@Zackster, I rebased, restored the deleted code, and submitted PR.

I don’t have enough experience to feel comfortable trying what you suggested with the no-JRE version without fear of breaking something else. :flushed:

Anyways I’ve already gone beyond the scope of what I wanted to contribute. :slightly_smiling_face:

1 Like
11

great, thanks jumping and getting your hands dirty!

I’ll review tomorrow