iOS Build Environment Help Center
Windows:10
Builder:3.60.2
iOS: 17.0
After the pod install start and some of the pods are downloading this happens
% Connection to 127.0.0.1 closed by remote host. =========================== CocoaPods output END ============================ NOTICE: this command returned a non-success exit status (-1). %
Thank you in advance
What does your Podfile look like please ?
this is the pod file
% source 'https://cdn.cocoapods.org/' platform :ios, '11.0' target 'UnityFramework' do pod 'BranchSDK', '~>2.1.0' pod 'Firebase/Core', '10.15.0' pod 'Firebase/Messaging', '10.15.0' end target 'Unity-iPhone' do end use_frameworks! :linkage => :static %
It might be a VM crash.
When this happens, do you see a task named "cocoapods-daemon.exe" in the Windows task manager's process list ?
i did notice will test now and tell you the result
After testing it exited with an error while the demon is still active
Here is a screenshot: https://ibb.co/cvPKHcY
but shortly it was not found in the task manger. i don't know if this is a crash or not
I tested with your exact Podfile but I could not reproduce the problem. It'll be hard to investigate.
Assuming it might be a VM crash, perhaps this is due to a CPU compatibility quirk. Let's try something. Open the file called "cocoapods.cmd" located in the Toolchain\cocoapods subdirectory of the builder with your text editor. Locate the line that says:
% cocoapods.cmd line 245 echo CreateObject^("WScript.Shell"^).Run ".\cocoapods-daemon.exe -nodefaults -nographic !ACCEL_FLAG! -cpu max -smp !NUM_CORES! -m !MAX_MEMORY!M -hda %COCOAPODS_IMG% %SNAPSHOT_OPTION% -net nic -net user,hostfwd=tcp::!LISTEN_PORT!-:22", 0 1> daemon-start.vbs & wscript daemon-start.vbs %
And remove the "-cpu max" argument, so that it looks like:
% cocoapods.cmd line 245 echo CreateObject^("WScript.Shell"^).Run ".\cocoapods-daemon.exe -nodefaults -nographic !ACCEL_FLAG! -smp !NUM_CORES! -m !MAX_MEMORY!M -hda %COCOAPODS_IMG% %SNAPSHOT_OPTION% -net nic -net user,hostfwd=tcp::!LISTEN_PORT!-:22", 0 1> daemon-start.vbs & wscript daemon-start.vbs %
Then let me know if it helps please.
So for some reason without your fix, the podfile was installed without a problem after the weekend. do you recommend that I still try your bit of code to help you debug for future reference?
No. But keep this thread bookmarked somewhere and if and when it happens again, then do it and let me know.
It happened again today. I tried your fix but it didn't help
How much free RAM does your computer have left when you’re running CocoaPods ? You might be running out of memory. It’s consistent with what you describe.
CocoaPods does all its work in memory : booting the POSIX VM, starting Ruby, downloading pods, modifying project files, propagating changes… Depending on your project dependencies’ sizes you may need more memory for this operation than the available usable amount at this time on your computer.
We have 8Gbs of ram in our VPS with about 55% left when running cocca pods.i will test again and monitor the Ram behaviour more but earlier this week builds was working fine under the same condition. I know that cpu power is not guaranteed in virtual machine but is ram the same too?
I will test again and tell you the results.
After testing again. At the start of the pod install about 3.8 GBs are available and at it's peek before crashing 2.3 GBs of RAM is available. I also noticed that the command prompt was stuck at Installing FirebaseCoreInternal. After a while, I found that the ram usage decreased dramatically in with 5 GBs available indicating the cocoapods demon has crashed. It remained stuck like this for a while then the rest of the output was printed.
Here is the photo of the output:
https://ibb.co/wrmKGbC
RAM usage is not guaranteed on shared VMs, just like CPU resources. They use a "memory ballooning" technique. It would be good if you could test that on a real hardware.
Just after posting this reply, i went to investigate further the issue and it's a RAM issue like you mentioned. Windows says in the Task Manager that it has X amount of RAM available but it's not available it's the amount of RAM that could be available as some part of the RAM is used as a standby list. I downloaded ISLC and prurged the standby list and the pods installed just fine.
Update: The Pods are not being installed again.
I'm currently testing on real hardware and I think everything will go fine I will be looking to upgrade the VPS to better specs. But in the meantime, I thought about downgrading back to v3.58 where this problem didn't happen to me. do you recommend this?
And if you do how do I download a Previous version of the builder?
Thanks in advance.
I really don’t recommend doing it as the previous CocoaPods VM was based on an aging version of CocoaPods that was starting to cause problems.
Instead, try editing Toolchain\cocoapods\cocoapods.cmd with a text editor and set the max ram variable in it to a lower value.
Update: After Upgrading our VPS to a 16 GB machine the builds are back to normal for now without any errors confirming it's a ram limitation problem.
Thanks again for the help and helping me identify the problem
You’re welcome. Thank you for the update.
Windows:10
Builder:3.62
iOS: 17.2
The same error happened again recently in both the VM and a New dedicated server we bought with 64 GBs of RAM. Any idea what could have caused it?
Unfortunately at first sight I'm unable to tell what's the problem.
The CocoaPods VM is based on the well-known x86_64 emulator qemu. The exact version is 20200201 - because it's the last version to my knowledge which still has Win7 support. Since you don't need Win7 support here's something you can try. Backup your Toolchain\cocoapods directory first. Then download the most recent qemu binary release (here are precompiled binaries at https://qemu.weilnetz.de/w64/), extract the installer (or install it in its default location) and copy over the DLL files and the qemu-system-x86_64.exe file in the Toolchain\cocoapods directory ; rename the latter one as "cocoapods-daemon.exe". Try again and see if the behavior is the same. Let me know if it fixes something.
Sorry for the late response.
We have been a bit busy with our releases lately so I haven't tried out your solution. I will try it out and tell you the outcome
Hi! I face with same problem. I have a lot of dependencies so build just stopped with same 'connection close' error. My solution is increasing some values in cocoapods.cmd file.
Here my settings:
set MAX_WAIT_TIME_SECONDS=320
set AUTOSHUTDOWN_SECONDS=1800
By default it is:
set MAX_WAIT_TIME_SECONDS=120
set AUTOSHUTDOWN_SECONDS=600
Pierre-Marie Baty, can you add to log message when VM stopped by timeout? It will be very helpful.
Thank you!
Thank you for the suggestion. I will do that.
*edit* MAX_WAIT_TIME_SECONDS is not used by the build.cmd script (it's used when someone calls "cocoapods.cmd wait"). So it can't have an effect. Curiously you say that increasing AUTOSHUTDOWN_SECONDS solved your problem, but the automatic shutdown is supposed to happen only when no connection is currently open between the daemon's VM and an external program, i.e. when it does nothing. This feedback instructs me that it's not quite the case and there's something I should fix here.
*edit 2* Okay I found the real problem.
Please open cocoapods.cmd with your text editor and look for the line that says:
% cocoapods.cmd !SEND_COMMAND_AS_ROOT! "IDLE_COUNT=0; while true; do sleep 10; ps ax|grep 'sshd: '|grep -v '[listener]'|grep -v grep > /dev/null && IDLE_COUNT=0 || IDLE_COUNT=$((IDLE_COUNT+1)); test $((IDLE_COUNT*10)) -gt %AUTOSHUTDOWN_SECONDS% && poweroff; done >&- 2>&- <&- &" %
Change it to:
% cocoapods.cmd !SEND_COMMAND_AS_ROOT! "IDLE_COUNT=0; while true; do sleep 10; ps ax|grep 'sshd: '|grep -v '\[listener\]'|grep -v grep > /dev/null && IDLE_COUNT=0 || IDLE_COUNT=$((IDLE_COUNT+1)); test $((IDLE_COUNT*10)) -gt %AUTOSHUTDOWN_SECONDS% && poweroff; done >&- 2>&- <&- &" %
Notice the backslashes between the brackets enclosing the word "listener". Those missing were the reason why the daemon would auto-shutdown after 5 minutes, no matter whether a Pod operation was active or not. The technical reason is that the POSIX pattern matching utility "grep" considers anything between brackets as a character range (regex rule) and if I want to match a _regular_ bracket (which is what I wanted here) then I must precede it with a backslash.
This fix will be in the next version :)
Moderators: Pierre-Marie Baty