peer(1) wants a heartbeat(5987) that we don't have.

[PGLubricants]

Hi!

I used to host a headless Factorio server in Azure Container Instances in 2020 and 2021 which worked without issues. It was based on the image, factoriotools/factorio. The setup is without any mods, or save game modifications. Just a clean instance.

When I try to use the same setup today in November 2022, I am unable to connect to the server, with the client error: "waiting for the server to save the map".

The server gives the error on startup: "12.938 Error InterruptibleStdioStream.cpp:61: Got EOF on stdin; closing", but then continues.
When attempting to connect, the server logs state:

Code: Select all

132.905 Warning ServerSynchronizer.cpp:112: nextHeartbeatSequenceNumber(7188) peer(1) wants a heartbeat(5987) that we don't have.

I suspect the issue could be related to the Windows hypervisor issue, mentioned here: viewtopic.php?f=49&t=103031.

Does anyone else experience this, or are you successfully running a setup in Azure?

I've attached the server logs if this has any interest.

[Loewchen]

See viewtopic.php?p=576257#p576257.

[PGLubricants]

Hi Loewchen,

Thank you for the pointer, but I cannot see how the problem is the same, or how the resolution can be applied here (to explicitly add UDP to the port, which already is the case). Can you elaborate on the similarities you see?

[Loewchen]

No, I have no other reason connecting those issues other than that they are happening while running it in a docker container and getting the EOF error right from the start.

[SoShootMe]

Thank you for the pointer, but I cannot see how the problem is the same, or how the resolution can be applied here (to explicitly add UDP to the port, which already is the case). Can you elaborate on the similarities you see?

This bit also appears in the linked thread, but my hunch is that it is a red herring (harmless and due to the container environment):

The server gives the error on startup: "12.938 Error InterruptibleStdioStream.cpp:61: Got EOF on stdin; closing", but then continues.

Other than that, you're running the server in a container but provided no details about the container, beyond the image and that it is in Azure Container Instances.

Although the error is the same as 103031, I'd be a little surprised if it was that problem as it was a few months back, but that is no guarantee. I think the advice in that thread stands: capture packets on the client and compare with a working case.

[PGLubricants]

Fair enough! I dismissed the container for now, and hosted the server on a VM instead, which is working just fine.

I'll let it rest for now, and continue the dialogue on the factoriotool pull request. Perhaps the visibility will draw some attention in google search results, if other Factorio Azure Container-explorers stumble upon this.