OSX 10.13: Finder got an error: AppleEvent timed out. (-1712)

[YngveNPettersen]

We have been using create-dmg for a while, with no problems.

Recently, we updated our Mac build machines to OS 10.13. Afterwards, the applescript part of the process have been failing with a timeout. Increasing the timeouts in the script to 600+ seconds did not help.

For reference, the script is run via ninja inside a buildbot instance (customized version of Chromium's), started on boot, display not connected, with screensaver.

Based on logging, it seems that the timeout happens in the open statement, or in the section before "tell container window". There have been one case, during the test of the upgrade to 1.0.0.4, when the failure apparently happened in the "tell container window" segment.

Curiously, at present one of the machines is successfully running the script for the past several day, while except for a short period under specific circumstances, the other is still failing them.

What did happen on the machine that is running successfully was that for several days I was logged in via VNC to the machine, while testing a new buildbot system. I was also, for a shorter period, logged i via VNC to the other machine, and while I was logged in, the script worked successfully, but not after I logged out.

Another possible difference is that I did run a couple of manual builds via VNC on the machine that are now passing the build.

I have previously observed similar timeout behavior on OSX 10.13 with many of Chromium's unit tests. In that case the only workaround was to disable the screen-saver. I'd rather avoid that solution. The difference, though, is that that was third party executables, while in this case it is happening with native applications.

[Vithanco]

I get this message without knowingly changing the system. Only noticed yesterday, but worked ~2 weeks ago:

Running Applescript: /usr/bin/osascript "/var/folders/z_/rslqm13d1ts1h66yhpfn23l40000gn/T/createdmg.tmp.XXXXXXXXXX.n7UpuGVD" "AppName Installer"

waited 351 seconds for .DS_STORE to be created.

I am running macOS 10.14 (Mojave)

[aonez]

@themadone what version of the script are you running?
@YngveNPettersen can you check if re-adding the lines removed in this commit bb4651b#diff-464fa7a4da97e2418055f7aa5d14ee1a have any impact on your tests? This lines removed are the only change since 2015.

[Vithanco]

Latest version. I even double checked via brew upgrade create-dmg. I assume that makes it 95ea395

[aonez]

@themadone can you also try re-adding the lines removed in this commit bb4651b#diff-464fa7a4da97e2418055f7aa5d14ee1a and let me know if they have any impact on your tests?

[YngveNPettersen]

The problem existed in both old and new versions of the file (in fact, updating to the version removing those lines was to tests if something had fixed it since we started using it).

Additionally, the script never gets that far; I inserted logging in the script and when the timeout happens it has never gotten to line 15 (although, one case while testing the upgrade to current code base, it did get to line 15, but not to line 24)

[Vithanco]

That seem to have worked.
waited 1 seconds for .DS_STORE to be created.
Thanks!

[aonez]

@YngveNPettersen would be interesting to see exactly up to what line it goes. From 6-13 there're only set commands:

https://github.com/andreyvit/create-dmg/blob/95ea395d877db64e28a23610e13e66698546f5d7/support/template.applescript#L6-L13

So maybe it hangs somewhere here:

https://github.com/andreyvit/create-dmg/blob/95ea395d877db64e28a23610e13e66698546f5d7/support/template.applescript#L1-L4

Or in line 15 that you mentioned:

https://github.com/andreyvit/create-dmg/blob/95ea395d877db64e28a23610e13e66698546f5d7/support/template.applescript#L15

[aonez]

@themadone removing the update lines again does replicate the long time .DS_STORE wait?

[Vithanco]

good thinking. And indeed. Undoing it didn't change the outcome.
The problem came. Then problem went. (at least that is how it now looks)

[aonez]

@themadone hehehe! Thanks for the testing. In your case maybe it was that the disk/system was really busy that time.

[Vithanco]

I had it more than once on that day. Not sure how, but will try to observe. Thanks for looking into this. Much appreciated!

[YngveNPettersen]

Yes, that open line is my primary suspect, and I have been thinking of increasing log density there, but have not gotten that far yet

[YngveNPettersen]

Did a test with more detailed logging: The failing machine never got past the "open" statement on line 4

[aonez]

@YngveNPettersen can you check the DMG is created and mounted before the Applescript is executed?

[YngveNPettersen]

On Sat, 08 Dec 2018 19:02:43 +0100, aONe ***@***.***> wrote: @YngveNPettersen can you check the DMG is created and mounted before the Applescript is executed?

AFAICT the DMG has been created, is mounted, and there are multiple file operations (including file copying) performed using the create-dmg script before the applescript is called. After the whole create-dmg script has completed, the DMG file works as intended, but is missing the layout generated by the applescript.

[ftrusa]

It's because of the new security restrictions in Mojave. You need to add permission in System preference -> Security&Privacy -> Privacy tab and i think Accessibility section to Terminal. After that it should work when you run it as logged in user.

Unfortunately it does not solve my problem when I'm executing create-dmg over ssh on the mac machine. Any help would be appreciated.

[YngveNPettersen]

On Fri, 14 Dec 2018 18:50:04 +0100, Frantisek Trusa ***@***.***> wrote: It's because of the new security restrictions in Mojave. You need to add permission in System preference -> Security&Privacy -> Privacy tab and i think Accessibility section to Terminal. After that it should work when you run it as logged in user.

Thanks, will check that out; although our system is not running Mojave, but 10.13 (High Sierra).

Unfortunately it does not solve my problem when I'm executing create-dmg over ssh on the mac machine. Any help would be appreciated.

My experience with code signing on Mac indicates that any task with UI interactions (code signing needs the keychain, create DMG opens finder windows) unfortunately have to be started from a GUI session (screenshare works fine), AFAIK it is not possible to run such tasks over an SSH connection. Sorry.

…

-- Sincerely, Yngve N. Pettersen Vivaldi Technologies AS

[ftrusa]

@YngveNPettersen Not related to this problem, but you can open keychain with command in bash script and somehow the apple script is able to handle changes in finder without opening it. This was working until update to 10.14 (Mojave). After that we've got the same error, but ours is OSX security related I'd say.

[luisangelsm]

AFAICT the DMG has been created, is mounted, and there are multiple file operations (including file copying) performed using the create-dmg script before the applescript is called. After the whole create-dmg script has completed, the DMG file works as intended, but is missing the layout generated by the applescript.

This is exatly what I am experiencing when using create-dmg in azure pipelines (macOS-10.14 image), it works perfetly fine locally in my mac book. It is installed using brew. Is there any workaround or fix?

[NicolasDorier]

I think there is no workaround but to run in a GUI and just copy the .DS_Store and .fseventds in your repository.

[digarok]

This still seems to be an unresolved issue stemming from a desktop UI request to grant permissions to run the AppleScript. In my case, I'm trying to run this from Github Actions builders, and of course it's failing.
/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/createdmg.tmp.XXXXXXXXXX.ac1Fa4XJ:396:408: execution error: Finder got an error: AppleEvent timed out. (-1712)

This affects the layout of the final DMG file, as it appears create-dmg is updating the icon layout and background with this script. However, if you don't see this as fatal, you can use the undocumented flag --skip-jenkins to avoid that step and at least you'll have working CI/CD with a vanilla DMG file.

I consider that a workaround for my scenario, but I do hope to have time to revisit this to see if I can grant permissions prior to the AppleScript invocation. If there are other ways to manipulate DMG files, I'd love to know. It seems this is somewhat the de facto app packaging tool for DMG.

[tomaszkoperski]

Seeing the exact same issue when run from a bitrise.io workflow.

[lgblgblgb]

Same problem here! I use Travis CI to build my project for MacOS. It runs:

ProductName:     Mac OS X
ProductVersion:  10.14.4
BuildVersion:	 18E226

I use create-dmg installed via homebrew:

Installing create-dmg formula. It is not currently installed.
==> Downloading https://homebrew.bintray.com/bottles/create-dmg-1.0.0.5.mojave.bottle.tar.gz

Actual part where I need to wait about 2 minutes to time out:

Running Applescript: /usr/bin/osascript "/var/folders/17/5mc7816d3mndxjqgplq6057w0000gn/T/createdmg.tmp.XXXXXXXXXX.e1LHQhEJ" "Xemu Installer"
/var/folders/17/5mc7816d3mndxjqgplq6057w0000gn /T/createdmg.tmp.XXXXXXXXXX.e1LHQhEJ:396:408: execution error: Finder got an error:   AppleEvent timed out. (-1712)

[TheLastProject]

I started to run into this issue on my Travis macOS builds (10.14) and I can confirm using the --skip-jenkins flag made the build succeed.

Pext/Pext@0835c61 is Pext's last broken commit and https://travis-ci.org/github/Pext/Pext/jobs/698645042 is the failed build, if this helps anyone debug things (yes, it looks succeeded but it fails because there's no .dmg in the end)

[CodeStage]

We have this issue on a GitLab runner, but strangely enough it works on another runner just fine. I have not found out the difference between the two machines yet.

I fixed it by connecting with VNC to the worker and accepting in the UI when a prompt "gitlab-runner wants to access finder" was displayed (before the script timeout). After doing that once it kept working without manual interference. I could not figure out how to do this in Security & Privacy and I don't see an entry for gitlab-runner anywhere now that it works... It sure would be good to know how to configure this without VNC an waiting for the prompt...

Maybe we can conclude that this is not an issue in create-dmg, but rather an issue of CI systems.

[lukaso]

Given this issue is still open, and I've seen it in the wild, I've been trying to get a bit more insight into what is happening. This commentary on fixing it in github actions seems to point to some possible solutions: actions/runner-images#553. Hopefully this is helpful.

[lukaso]

This fixes the problem for Circle CI builds (thanks to Circle CI support for providing the fix!)

Add these in the step in config.yml where you are calling create-dmg. It requires SIP (System Integrity Protection) to be turned off. Also, circle ci calls the steps from sshd so if that is not what's calling your steps in your CI solution, you will need to change that aspect.

Anyway, here it is:

epochdate=$(($(date +'%s * 1000 + %-N / 1000000')))
tcc_service_appleevents="replace into access (service,client,client_type,auth_value,auth_reason,auth_version,indirect_object_identifier_type,indirect_object_identifier,flags,last_modified) values (\"kTCCServiceAppleEvents\",\"/usr/sbin/sshd\",1,2,4,1,0,\"com.apple.finder\",0,$epochdate);"
sudo sqlite3 "/Users/distiller/Library/Application Support/com.apple.TCC/TCC.db" "$tcc_service_appleevents"

[nljohnson]

This fixes the problem for Circle CI builds (thanks to Circle CI support for providing the fix!)

Add these in the step in config.yml where you are calling create-dmg. It requires SIP (System Integrity Protection) to be turned off. Also, circle ci calls the steps from sshd so if that is not what's calling your steps in your CI solution, you will need to change that aspect.

Anyway, here it is:

epochdate=$(($(date +'%s * 1000 + %-N / 1000000')))
tcc_service_appleevents="replace into access (service,client,client_type,auth_value,auth_reason,auth_version,indirect_object_identifier_type,indirect_object_identifier,flags,last_modified) values (\"kTCCServiceAppleEvents\",\"/usr/sbin/sshd\",1,2,4,1,0,\"com.apple.finder\",0,$epochdate);"
sudo sqlite3 "/Users/distiller/Library/Application Support/com.apple.TCC/TCC.db" "$tcc_service_appleevents"

I came here yesterday looking to see if anybody else had dealt with this. I didn't see that error in CircleCI, but I realized there was going to be an issue when I got the prompt for permissions while prototyping locally. CircleCI has an orb to help set permissions, but it doesn't seem able to handle this case. Thanks for sharing the response they gave you, I've confirmed it works on my case. You need to be using Big Sur or later to use this exact version, as I found there were some changes in TCC.db at that point. Doing a deeper dive here:
https://rainforest.engineering/2021-02-09-macos-tcc/

[wetduck]

I recently started running into this issue and while investigation is early, I believe for me it is related to multiple jenkins jobs attempting to prettify the gui at the same time. Ie, two jobs with two separate workspaces are creating a dmg that would mount with the same name if they were mounted at different times.

[tyteen4a03]

Same error here - none of the workarounds worked (we're still on 10.15). Any chance of a fix?

[VitoVan]

I can confirm this is fixed by adding --skip-jenkins on macos-13