Recent changes to bugs

#327 Update mac os implementation to use launchctl bootout bootstrap

2025-10-17T12:05:56.882000Z

Hi Jonathan,

Thank you again for your contribution.

We have implemented changes similar to your suggestions.

However, we found that instead of waiting for process termination, it is more reliable to wait for the service to be unbooted by launchd.
launchd normally sends a TERM signal to the process and unloads it upon confirmation of termination, but there can be a slight delay between the process stopping and the service actually being unloaded.
Attempting to execute launchctl bootstrap might result in an error like the following:

service already bootstrapped
Bootstrap failed: 37: Operation already in progress

The fix will be available in the next Wrapper release.

Best Regards,

Maxime

#327 Update mac os implementation to use launchctl bootout bootstrap

2025-09-26T07:08:20.554000Z

Hi Jonathan,

Thank you very much for bringing this issue to our attention.

I believe 'launchctl bootout/bootstrap' was introduced in macOS 10.10 Yosemite. The current Wrapper still supports older macOS versions, so we need to maintain compatibility for now. But we plan to raise the system requirements in the next release (3.7.0), which will allow us to implement macosxRestart() as you've suggested.

When restarting the Wrapper, we typically call waitForWrapperStop() in the shell script, which uses a loop similar to your proposed code. We could also introduce a timeout as you suggested.

We will update this thread once this change is implemented.

Thank you again for your suggestion.

Best regards,

Maxime Andrighetto

Update mac os implementation to use launchctl bootout bootstrap

2025-09-25T16:37:29.899000Z

launchctl's load and unload commands are considered legacy at this point and swapping to bootout and bootstrap should be fairly trivial.

instead of:

launchctl unload "/Library/LaunchDaemons/${APP_PLIST}"
launchctl load "/Library/LaunchDaemons/${APP_PLIST}"

it becomes

launchctl bootout "system/${APP_PLIST_BASE}"
launchctl bootstrap system "/Library/LaunchDaemons/${APP_PLIST}"

also, while we are in here we should alter the macosRestart() function to actually wait for the process to be stopped instead of a hardcoded sleep 1 like so:

macosxRestart() {
    mustBeRootOrExit
    checkRunning $1

    eval echo `gettext 'Restarting $APP_LONG_NAME...'`

    if [ "$MACOSX_KEEP_RUNNING" = "true" ] ; then
        # by stopping it, launchd will automatically restart it
        launchctl stop ${APP_PLIST_BASE}
    else
        launchctl bootout "system/${APP_PLIST_BASE}"
        timeout=60
        while [ $timeout -gt 0 ] && pgrep -f "$PIDFILE" > /dev/null; do
            sleep 1
            ((timeout--))
        done
        launchctl bootstrap system "/Library/LaunchDaemons/${APP_PLIST}"
    fi

    startwait
}

#326 ./server.sh start fails to start Java application when the application installation path contains a space

2024-11-13T03:29:11.987000Z

status: open --> open-accepted

./server.sh start fails to start Java application when the application installation path contains a space

2024-11-13T00:02:23.737000Z

How Found:
When attempting to start a Java application installed on Amazon Linux 2023 and Rocky Linux 9 environments.

Expected Outcome:

The application starts up normally.

Actual Outcome:

The application does not start and an error is output to the console. For example, if the installation path is /opt/foo bar the error on the console is:

Unable to locate any of the following binaries:
/opt/./wrapper-linux-x86-64
/opt/./wrapper-linux-x86-32
/opt/./wrapper

./server.sh start fails to start Java application when the application installation path contains a space

2024-11-13T00:02:23.737000Z

Ticket 326 has been modified: ./server.sh start fails to start Java application when the application installation path contains a space
Edited By: Maxime Andrighetto (maxime-tsl)
Status updated: 'open' => 'open-accepted'

#325 Tanuki wrapper is creating large number of wrapper.log files

2024-06-25T06:26:53.626000Z

This problem is now fixed in version 3.5.58.
https://wrapper.tanukisoftware.com/doc/english/release-notes.html#3.5.58

#325 Tanuki wrapper is creating large number of wrapper.log files

2024-06-25T06:25:36.487000Z

Description has changed:

Diff:

--- old
+++ new
@@ -1,3 +1,2 @@
-

 We have created  wrapper service for Opensearch service. On one of the service wrapper did not have access to log file location given for wrapper log file. Hence wrapper created the log file in the working directory with name as wrapper.log. However it was observed that &#34;wrapper.logfile.maxfiles&#34; is not getting honored in this scenario. We have given max number of files as 10 but it created more than 800 log files. Please find attached screenshot for the same

status: open-accepted --> closed-fixed

#325 Tanuki wrapper is creating large number of wrapper.log files

2024-06-12T11:27:43.571000Z

Thanks Maxime for quickly triaging the issue. Yes each file was of 5Mb size.

#325 Tanuki wrapper is creating large number of wrapper.log files

2024-06-12T11:22:28.876000Z

Thank you for your reply.

I was able to reproduce the issue. It first appeared in version 3.5.37.
We will of course fix it for the next release, but in the meantime you may use version 3.5.36.

I just want to confirm the size of your rolled log files. Are they 5Mb each?

Best Regards,

Maxime