Improbable Icon


13.5.1 Failed to start managed worker


Hi. I haven’t been uploading my deployment since somewhere around 12… something. I have read through the whole documentation for the newest runtime and did necessary changes. When I try my deployment on local linux machine, it loads my managed worker and managed worker simulates properly, it’s all good. But in the cloud, I get message:
Failed to start managed server-worker Server0: Timed out waiting for the worker to connect to the Runtime after 60000ms…
I have tweaked this worker timeout limit by using legacy flag, and only the numbers here change. Whether it’s 60000ms or 10000000ms, It is timed out. I don’t understand how, because as I said, the same managed worker runs perfectly on my machine.


Just updated to 13.6.0 and the issue is there too.


Yes, same for me. I started testing SpatialOS FPS demo project few days ago. I followed all instructions on the tutorial, but I never be able to deploy it in the cloud. I’ll start over and try it again in a few hours, then update my results.

Using macOS, Unity 2018.3.5f1


Any updates ? I am using Unreal engine but with my custom implementation. I am quite knowledgeable about spatialos systems, because I have implemented it to two engines from scratch, and from my experience, check if your managed worker has the right worker id assigned while starting. Unfortunately this is not the case for me. For me it works perfectly on my local linux machine, but on the cloud… I have no idea what’s going on.


I am experiencing the same issue when uploading my own project to the cloud with the same log message.

Failed to start managed server-worker UnrealWorker0: Timed out waiting for the worker to connect to the Runtime after 30000ms. Requesting to stop the worker process.

Also no issues on my end when deploying locally …


Hey Guys

Could you check the Raw Log folder see if you could find anything over there ? Also a common cause for this issue could be ${IMPROBABLE_RECEPTIONIST_HOST} not used but get hardcoded on local host.Which means the worker will never reach out to the receptionist to estabilish the connection with runtime.

${IMPROBABLE_RECEPTIONIST_HOST}: the IP or hostname where a managed worker should connect to.

Let me konw how it goes .

Best Regards



I do set the receptionist host and port from these variables as I always did. There’s no way that this could be the case. Raw logs don’t give me any informations aside the fact that the next worker will be run. I would like to log some messages from my worker, but connection is not established. Could you guide me on how to save some custom log file and later access it from raw logs menu? That’s the way I could check a lot of things.



Do you mind starting you deployment again and keeping it running? We can try to have a look on our side and see if there is anything weird we can see.

Best Regards



Unfortunately I am currently at work, I will be able to do it over the weekend or on monday. But maybe some of the other people having this issue can try, if so, please let me know what’s the conclusion.


Is it ok if I start your deployment for 5-10 minutes to try to debug this issue?


Hi @Fury,

Sorry for the delay with getting back to you. We have recently added a new feature that allows you to see more complete logs of your worker startup. They can be accessed from the “Raw logs” link. If you navigate to the file that looks like YOUR_WORKER_NAME_HERE_stdout_stderr.log you can see extra logging around engine startup. In your case the failure is following
“Refusing to run with the root privileges.”

This is due to Unreal constraint, it does not allow running Unreal as root. I am following up internally about the best way to resolve this for you and will get back with a proposed fix shortly.


Amazing! I’ll be waiting. I will also do research on my side.


Just checked that out. I don’t seem to have this file there. All I have is:

That’s it. I also searched above in that hierarchy, but couldn’t find it.


You will want to click on the “worker_nanny” node before clicking raw logs:

With regards to the running as root issue, the GDK for Unreal runs the Unreal server binary as a different user in the startup script:


I am not using Unreal GDK or sdk. I have my own implementation. However it’s good to look at. I will experiment with it.

I just remembered how I used to fix this issue long time ago.

I will try that out tomorrow and update this topic


Yup. That solved the issue. So for anyone going through this in the future:

  1. Go to your Unreal Engine solution, find file: Source/Runtime/Core/Private/Unix/UnixPlatformMemory.cpp
  2. Go to line 37 (UE 4.21.2) or if it has changed its place, find line: “#define UE4_DO_ROOT_PRIVILEGE_CHECK 1”
  3. Change “1” to “0”.
  4. Compile, deploy your assembly, voila :slight_smile: it works.

Note that as it was stated in the post from Unreal Engine forum I have posted before, It isn’t 100% safe. So it’s on you if anything happens :wink: