Building DMG with Composer is very slow

[jskidmore]

Currently,
I am trying to build a DMG of Oracle SQL Developer so as to list it in Self-Servive. SQLDeveloper is nothing more than a '.app' program that can be dragged and dropped into the Applications folder.

I take a snapshot, copy the file to the Applications folder, take another snapshot for the package source. I then try to build as a DMG, but it takes an extraordinary long time. I let this process run over the 4th of July Holiday and came back and the DMG was still not complete.

Furthermore, building other DMG files (Java JRE and JDK) also take a lot longer than I remember it taking before. It seems to take hours (3 hours +) to build a DMG.

Any ideas, suggestions, comments?

[donmontalvo]

Why do you need a snapshot if it is a drag install?

Drag the app to the left pane in Composer. Done.

[dwandro92]

@donmontalvo makes a good point, however I think you will find that it would still take longer than normal to build the package.

Here are my suggestions/comments:

If you have anti-virus installed on the machine which performs on-access scanning (OAS), try temporarily disabling OAS and see if you get the same results.

If the above suggestion doesn't apply or produces no drastic change, try the procedure below. I don't know if it will fix the problem, but I suppose there is a chance:

1. Close the Composer application.
2. Open the Terminal application.
3. Execute the following command: sudo find /private/var/folders -iregex '.jamf.composer.*'.
4. If the above command begins to produce an inordinate number of results, terminate the command using Control + C, then remove the files using the following command: sudo find /private/var/folders -iregex '.jamf.composer.*' -delete. NOTE: This could take a while!

Background story: One fateful day, the 2013 Mac Pro that I used as my primary system wouldn't start up - the progress bar which appears at startup would fill completely, but the login screen never appeared. I was unable to resolve the problem using standard troubleshooting procedures (NVRAM and SMC reset, Safe Boot mode, First Aid, etc.). After at least an hour of troubleshooting in Single User mode, I learned that there was an extraordinary number of temporary files created by Composer - presumably for snapshots - under the /private/var/folders directory. I tried to remove them, but after letting the command run for almost 30 minutes, I still hadn't even made a significant dent. I ended up renaming /private/var/folders and creating an empty directory in it's place. When I rebooted, the machine did some weird things while it was re-populating the directory, but it finally started up! When it was time to leave for the day, I executed the command to remove the original directory and let it run completely overnight.

[jskidmore]

I was able to create the DMG file on another machine. I'll review the /private/var/folders directory and see if old snapshots are causing an issue.

[donmontalvo]

Since I'm on stay-cation, taking a break in between schlepping boxes from old to new apartment, thought I'd run a quick test.

Using WhiteBox Packages, I put the downloaded ZIP archive into /private/tmp/.sqldeveloper/ (dot added to hide folder), then used a script to unzip it into place, preserving owner:group and permissions.

This took about 5 minutes to complete.

postinstall script:

#!/bin/sh

/usr/bin/unzip /private/tmp/.sqldeveloper/sqldeveloper-4.2.0.17.089.1709-macosx.app.zip -d /Applications/

exit 0

Ran the PKG using Terminal, took a bit over 8 seconds to install.

bash-3.2# time installer -pkg /Users/admin/Desktop/Oracle_SQLDeveloper_4.2.0.17.089.1709.pkg -target / -verbose
installer: Package name is Oracle_SQLDeveloper_4.2.0.17.089.1709
installer: Upgrading at base path /
installer: Preparing for installation….....
installer: Preparing the disk….....
installer: Preparing Oracle_SQLDeveloper_4.2.0.17.089.1709….....
installer: Waiting for other installations to complete….....
installer: Configuring the installation….....
installer:  
#
installer: Writing files….....
#
installer: Writing files….....
#
installer: Running package scripts….....
#
installer: Running package scripts….....
#
installer: Running package scripts….....
#
installer: Running package scripts….....
installer: Running package scripts….....
installer: Running package scripts….....
installer: Running package scripts….....
installer: Running package scripts….....
installer: Running package scripts….....
installer: Running package scripts….....
installer: Running package scripts….....
installer: Validating packages….....
#
installer:  
installer: Finishing the Installation….....
installer:  
#
installer: The software was successfully installed......
installer: The upgrade was successful.

real    0m8.285s
user    0m0.085s
sys 0m0.058s
bash-3.2#

[jskidmore]

Still finding that Composer is taking a very long time. I have tried out WhiteBox Packages and it is a lot faster. I need to find out why everything in Composer is taking so long. I will probably create a ticket for JAMF to review. If I find anything out I'll update this thread.

[jskidmore]

I found out the issue... We use Symantec Data Loss Prevention (DLP) and that was the cause of our slow Composer issues. On another note, WhiteBox Packages is a fantastic application. Thanks for sharing it in this thread.

[bethjohnson]

+1 to real-time protection causing issues. We just switched to a new antivirus product and my DMG builds slowed to about 1% per five minutes. Turned off real time protection, and zip! Done in seconds.