Recent changes to bugs

#327 Update mac os implementation to use launchctl bootout bootstrap

Maxime Andrighetto — Fri, 17 Oct 2025 12:05:56 -0000

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

Maxime Andrighetto — Fri, 26 Sep 2025 07:08:20 -0000

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

Jonathan Coffman — Thu, 25 Sep 2025 16:37:29 -0000

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

Maxime Andrighetto — Wed, 13 Nov 2024 03:29:11 -0000

status: open --> open-accepted

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

Mohammed Fahed Shareef — Wed, 13 Nov 2024 00:02:23 -0000

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

Mohammed Fahed Shareef — Wed, 13 Nov 2024 00:02:23 -0000

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

Maxime Andrighetto — Tue, 25 Jun 2024 06:26:53 -0000

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

Maxime Andrighetto — Tue, 25 Jun 2024 06:25:36 -0000

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

Swapnil Vaidya — Wed, 12 Jun 2024 11:27:43 -0000

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

Maxime Andrighetto — Wed, 12 Jun 2024 11:22:28 -0000

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