Valkyrien Skies (Forge/Fabric)

Valkyrien Skies (Forge/Fabric)

3M Downloads

Server is shutting down

LieSain1 opened this issue ยท 10 comments

commented

Mod Name

valkyrienskies-119-2.1.2-beta.1

This issue occurs when only Valkyrien Skies, addons, and the mod I have specified are installed and no other mods

  • I have tested this issue and it occurs with only Valkyrien Skies, addons, and the mod I have specified

Minecraft Version

1.19

Mod Loader

Fabric

Issue description

Running the server on a remote VM.

Issue reproduction

Running the server

Logs

Without modification of valkyrienskies and its dependencies, the server starts up quietly.

I must say right away, I use the pterodactyl panel for the convenience of running servers.

And with it, it is not possible to start the server with modifications in our build.

We tested it on another VM where there is no Pterodactyl panel, everything turned out to run there.

The assumption is that the server/modification is trying to access something that it does not have rights to.

https://hastebin.com/share/fuduwokeba.yaml

https://hastebin.com/share/qotusujoda.ruby

commented

@thetheaplant is partially correct here. Pterodactyl, or specifically its docker wrapper "wings", will kill the container if it spawns too many processes, which can throw memory errors as the program was not-so-gracefully terminated. Presumably, VS2 spawns a load of threads for the physics engine, leading to a total of > than 512 total processes, thus hitting the default container max and silently killing the process. Specifically, this is related to the container_pid_limit attribute at /etc/pterodactyl/config.yml/.

The fix is pretty simple.

  1. Go to /etc/pterodactyl/config.yml
  2. Change the docker process limit to 0 like such:
docker:
  ...
  container_pid_limit: 512
  ...
  1. Restart wings & all servers

This definitely needs to throw a different error. The documentation for this configuration option can be found at https://pterodactyl.io/wings/1.0/configuration.html.

commented

We've seen pterodactyl crash VS2 before, something about it's ram management conflicts with vs2. the error is from vs2 saving data to a set of static ram addresses and being unable to retrieve it.

commented

I have root access, how can I fix this problem?

commented

You're going to have to look through pterodactyl's documentation, if there's any sort of a resizable or dynamic ram, disable it. The best way is honestly just bare metal.

commented

did I understand correctly that vs2 is trying to write data to specific ram addresses? If so, this is complete nonsense. And if I already have another server on my vm and it already uses these memory cells

commented

I'm not that familiar with byte buffer, you have the java errors in the log. The errors reflect a previously valid location becoming invalid for whatever reason, but this is not a VS issue.

commented

It is trying to use specific ram addresses, yes, Krunch uses the bytebuffer method. SIGSEGV reflects the JVM trying to access an invalid memory location.

commented

Is this nonsense? The RAM is dynamic for that. To record constantly new information in it. This is already some kind of assembler level..

commented

It works on bare metal, do not expect this to be fixed unless the physics engine is changed.

commented

seems to solved