Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Server crashes on first player join #6564

Closed
Bobder opened this issue Jan 6, 2025 · 2 comments
Closed

Server crashes on first player join #6564

Bobder opened this issue Jan 6, 2025 · 2 comments
Labels

Comments

@Bobder
Copy link

Bobder commented Jan 6, 2025

Modpack

FTB StoneBlock 3

Modpack version

1.11.2

Launcher

Server

Has the pack been modified

No

Log Files

https://pste.ch/xihayikare.sql

Describe the bug

After starting the server using run.sh, the server's console repeatedly shows Can't keep up! Is the server overloaded? Running 16752ms or 335 ticks behind with these numbers increasing over time. ~30-60s after a player attempts to join, the server crashes.

This is a pre-existing server that had been operating normally with no real hitches for ~1 week. Our usage of Refined Storage and Functional Storage have increased significantly recently, so I suspect they may be the cause.

Moving/renaming the world folder so the server starts with a fresh world works, clients are able to connect, and no lag or other issues are observed.

Steps to reproduce

  1. execute ./run.sh
  2. wait for server startup to complete
  3. attempt to connect from a client
  4. server crashes after ~30-60 seconds
    (Have tested with local network clients using 1.11.1 via PolyMC, and 1.11.2 via FTB launcher)

Expected behaviour

Client/player is able to join

Screenshots

No response

Additional information

Happy to provide any other details needed, I'm fairly technically-minded so just let me know if anything more is needed.

@Gaz492
Copy link
Member

Gaz492 commented Jan 7, 2025

This may not fix the actual issue you are having, but it may help the server get over the issue its having.
In the server.properties change the max-tick-time setting to -1, then start the world and try connecting to it, it will probably time you out and not let you join, but there is a chance that it will let the server fix itself.

Other things you can try to do, is run the command /forge entity list in the console of the server as soon as you connect to the server, this will list out all entities you have in your world, if you see any specific entity over 500 you should run /kill @e[type=THE_ENTITY_HERE] e.g. /kill @e[type=minecraft:item]

@github-actions github-actions bot added the state: Awaiting Reply A reply is awaited from a user. label Jan 7, 2025
@Bobder
Copy link
Author

Bobder commented Jan 7, 2025

Thanks for the quick response, Gaz!

I changed the max-tick-time to -1 as mentioned, this prevented the server from crashing due to a timeout as expected. Unfortunately, the client wasn't able to load the world. It just gets stuck on "Loading Terrain".

Attempting to run forge entity list from the server console before joining shows [Server thread/INFO] [minecraft/DedicatedServer]: No entities found.
After the client begins joining, the command does not complete and no response is returned. Regardless, I tried kill @e[type=minecraft:item] but again there is no output returned and the behavior remains unchanged.

After rebooting the server and prepping the /kill @e[type=minecraft:item] command in advance, I attempted to join from my client. Quickly I switched back to the server console and began spamming the /kill @e[type=minecraft:item] command. This killed 313896 entities, and I was able to successfully join the server once again.

Fairly certain my lava egg -> create drain -> refined storage pipeline is the culprit. This area was only partially chunkloaded using FTBChunks (or whatever that minimap claiming/chunkloading mod is called these days, button is accessible from top right of inventory). Interestingly, it seems the set of smart chutes in unclaimed chunks that I was using to drop the eggs were able to drop eggs while no users were online. Since this area was not chunkloaded, the eggs were not being processed by the drains, and a client connecting would have to load all of the eggs that have built up since the last login. Too many eggs and the server is brought to it's knees.

Thanks for again for the quick response, and nice job hitting the nail on the head with that recommendation!!

@Bobder Bobder closed this as completed Jan 7, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants