Server is shutting down - Githubissues

ValkyrienSkies / Valkyrien-Skies-2

Valkyrien Skies 2

https://valkyrienskies.org/

GNU Lesser General Public License v3.0

205 stars 77 forks source link

Server is shutting down #826

Closed LieSain1 closed 1 month ago

LieSain1 commented 1 month ago

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

[X] 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

thetheaplant commented 1 month ago

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.

LieSain1 commented 1 month ago

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

thetheaplant commented 1 month ago

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.

LieSain1 commented 1 month ago

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

thetheaplant commented 1 month ago

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.

LieSain1 commented 1 month ago

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

thetheaplant commented 1 month ago

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.

thetheaplant commented 1 month ago

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

EricApostal commented 1 month ago

@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.

Go to /etc/pterodactyl/config.yml
Change the docker process limit to 0 like such:
```
docker:
...
container_pid_limit: 512
...
```
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.

Rubydesic commented 1 month ago

seems to solved