The STDIO streams did not close within 10 seconds of the exit event from process

[bdovaz]

@FejZa We have this problem when we target Android in an Oculus Quest 2 project with the official Oculus asset.

If I copy the same command line out of Azure Pipelines, the process ends up correctly.

If I run it from Azure pipelines with the UnityBuild task, it stays forever until the 60 minutes timeout.

I use a custom -executeMethod with -quit flag.

Cleanup mono
Exiting batchmode successfully now!
The STDIO streams did not close within 10 seconds of the exit event from process 'D:\tools\Unity\2020.3.17f1\Editor\Unity.exe'. This may indicate a child process inherited the STDIO streams and has not yet exited.
Unwatch D:\agent\_work\20\s\Logs\UnityBuildLog_2021-10-29-11-24-34.log
=============================== UNITY LOG END ================================
The Unity build completed successfully
##[error]The operation was canceled.

[BogdanDidukh2003]

Hello, I have the same issue, but in one try out of 10 it works as suppoused

[bdovaz]

@FejZa How are you doing with this? Did you come to any conclusions? Did you make any progress? We are still affected by it.

Thank you.

[Storm-Develop]

Same issue here: The STDIO streams did not close within 10 seconds of the exit event from process 'C:\Program Files\Unity\Hub\Editor\2020.3.33f1\Editor\Unity.exe'. This may indicate a child process inherited the STDIO streams and has not yet exited.

[NorbertNemec]

I'm newly encountering this issue after migrating from Unity 2021.3.21f1 to 2022.3.7f1. In my case, it happens on all calls to UnityBuildTask and UnityCMDTask (with -quit which correctly causes the process to exit).

I'm rather desperate - does anyone here have a workaround?

[marek-stoj]

Same issue here. Unity 2020.3.34f1.

[NorbertNemec]

Since my last post, I managed to find a reasonable workaround, by adding a dummy task before the actual UnityCMDTask:

• task: UnityCMDTask@1 displayName: UnityCMDTask Workaround Dummy inputs: unityProjectPath: $(Build.SourcesDirectory)\MyProjectPath
  cmdArgs: -quit timeoutInMinutes: 5 continueOnError: true

That task starts loading the project (which takes a few minutes anyway), then do nothing and time out after a few minutes. The subsequent UnityCMDTask would then start up rather quickly (since the caches are already filled by the dummy task), but since the project had been loaded before, the original issue of the hanging child process would no longer appear and everything would work just fine from there on.

The drawback of this approach is that the aborted continueOnError task would leave the entire job in a yellow warning state, even though it is technically fully successful.

[marek-stoj]

In my situation it is an adb.exe process that is kept running that prevents the job to continue. When I kill the process, the build succeeds. It is weird because the same codebase (with slight variations) on a different branch doesn't use adb at all and the build completes without issues 😕