Nodes don´t create a new world

DerLinkman commented 2 years ago

Hello,

very nice that someone started to dockerize the awesome multipaper project :)

But apparently it don´t work on my maschine because the servers cannot generate any World on my server.

Is the reason LXC? Or isn´t it working in general at the moment?

A quick log:

server1  | [18:11:58 WARN]: [org.bukkit.craftbukkit.v1_19_R1.util.WorldUUID] Failed to read world's uid.dat, generating new random UUID
server1  | java.io.EOFException: null
server1  |      at java.io.DataInputStream.readFully(Unknown Source) ~[?:?]
server1  |      at java.io.DataInputStream.readLong(Unknown Source) ~[?:?]
server1  |      at org.bukkit.craftbukkit.v1_19_R1.util.WorldUUID.getUUID(WorldUUID.java:22) ~[multipaper-1.19.2.jar:MultiPaper-1.19.2-36]
server1  |      at net.minecraft.server.level.ServerLevel.<init>(ServerLevel.java:511) ~[?:?]
server1  |      at net.minecraft.server.MinecraftServer.loadWorld0(MinecraftServer.java:594) ~[multipaper-1.19.2.jar:MultiPaper-1.19.2-36]
server1  |      at net.minecraft.server.MinecraftServer.loadLevel(MinecraftServer.java:430) ~[multipaper-1.19.2.jar:MultiPaper-1.19.2-36]
server1  |      at net.minecraft.server.dedicated.DedicatedServer.initServer(DedicatedServer.java:314) ~[multipaper-1.19.2.jar:MultiPaper-1.19.2-36]
server1  |      at net.minecraft.server.MinecraftServer.runServer(MinecraftServer.java:1137) ~[multipaper-1.19.2.jar:MultiPaper-1.19.2-36]
server1  |      at net.minecraft.server.MinecraftServer.lambda$spin$1(MinecraftServer.java:313) ~[multipaper-1.19.2.jar:MultiPaper-1.19.2-36]
server1  |      at java.lang.Thread.run(Unknown Source) ~[?:?]
master   | server92050 has requested world's level.dat, but it is empty. Retying in 10 seconds once server07464 has generated it...

This loops forever.

Either if i create it from "scratch" with no previous config or if i restart the stack it loops.

My docker-compose.yml looks like that:

---
version: "3"

services:

  master:
    container_name: master
    image: noevidenz/multipaper-master:latest
    ports:
      - 25565:25565 # Opens the proxy port
    volumes:
      - ./master:/app # Required to access world files

  server1:
    container_name: server1
    depends_on: 
     - master
    image: noevidenz/multipaper:latest
    environment:
      - EULA=true # Setting this to true will automatically accept the Minecraft EULA upon launch
      - JAVA_TOOL_OPTIONS=-Xmx4G
        -DmultipaperMasterAddress=master:35353 
        -Dspigot.settings.bungeecord=true

  server2:
    container_name: server2
    depends_on: 
      - master
    image: noevidenz/multipaper:latest
    environment:
      - EULA=true # Setting this to true will automatically accept the Minecraft EULA upon launch
      - JAVA_TOOL_OPTIONS=-Xmx4G
        -DmultipaperMasterAddress=master:35353
        -Dspigot.settings.bungeecord=true

If you need more informations please let me know.

DerLinkman commented 2 years ago

Retested it on a KVM VM. Same behaviour there!

I´ve noticed that the master node does not create any Data. Nor a config , not a world or a synced-server-files folder.

noevidenz commented 2 years ago

Hi @DerLinkman,

As weird as it appears, the error you shared is expected on first launch when the world files are missing and need to be generated.

You should see that error appear 3 times, once each for world, world_nether and world_the_end. It might then take a little while for the server to generate the level files.

During that time (if you're following logs for the whole stack) you should also see the second server repeatedly requesting the level files about every 10 seconds or so until the world files have all been generated by the first server.

I've tested using the docker-compose.yml file you provided and have been able to successfully start up the servers and connect using the official Minecraft Java client.

After launching the servers and waiting for levels to generate, this is the state of the master directory in my project:

master
├── world
│   ├── data
│   │   └── raids.dat
│   ├── level.dat
│   ├── region
│   │   ├── r.-1.-1.mca
│   │   ├── r.-1.0.mca
│   │   ├── r.0.-1.mca
│   │   └── r.0.0.mca
│   └── uid.dat
├── world_nether
│   ├── DIM-1
│   │   ├── data
│   │   │   └── raids.dat
│   │   └── region
│   │       ├── r.-1.-1.mca
│   │       ├── r.-1.0.mca
│   │       ├── r.0.-1.mca
│   │       └── r.0.0.mca
│   ├── level.dat
│   └── uid.dat
└── world_the_end
    ├── DIM1
    │   ├── data
    │   │   └── raids_end.dat
    │   └── region
    │       ├── r.-1.-1.mca
    │       ├── r.-1.0.mca
    │       ├── r.0.-1.mca
    │       └── r.0.0.mca
    ├── level.dat
    └── uid.dat

Can you please confirm the following:

Run docker-compose pull to make sure you're running the latest images (I've tested using noevidenz/multipaper:c44de528ce4a and noevidenz/multipaper-master:36b837dfdebf this afternoon)
Are you definitely seeing the same error repeated, not one for each of the missing levels in sequence?
Does waiting a bit longer (2-3 mins?) result in any files being written to the master folder? (Generating a new level can be quite slow)

If you're definitely still seeing the problem, please provide the following details:

Operating system & CPU architecture
the Image IDs being used
Which user is the owner of the master directory generated when running the containers? (And is this the same as the Docker user?)

DerLinkman commented 2 years ago

Hey :)

It is well known that the world generation takes some time, that's why MultiPaper exists... oh man Mojang :( but however he creates only the master folder and nothing in it. Neither the empty worlds folder nor anything else.

Even after the 2-3 minute wait.

The image IDs are: 06ea1587fa0c (multipaper) and ce1976c6e83b (multipaper-master) just did a docker-compose pull (removed the old images before).

OS is Debian 11, CPU architecture is x86.

noevidenz commented 2 years ago

Hi @DerLinkman,

I think I've been able to reproduce the issue you're facing using a fresh install of Debian 11.5 with Docker v20.10.18.

When starting up the services, if the master directory doesn't already exist, it is created for you by docker, however its owner is root:root.

Because the process inside the docker container is not running as the root user, it's unable to write to this directory.

You should be able to solve the issue in one of two ways:

Either recreate the master directory with the login user as owner:
1. cd into the project folder
2. Delete the existing master directory: sudo rm -rf master
3. Recreate it as the current user: mkdir master
4. Now that the folder exists, you can start up your services with docker compose up -d

Or force the multipaper-master service to run as the root user:

master:
container_name: master
image: noevidenz/multipaper-master:latest
user: root # this line sets the user inside the container
ports:
  - 25565:25565 # Opens the proxy port
volumes:
  - ./master:/app # Required to access world files

Hopefully this gets it working for you; let me know if there's still any problem.

DerLinkman commented 2 years ago

That looks a lot better now thank you!

Maybe you should write a notice on that issue at the Readme? So that no one will ask for this again (i´m pretty sure i´m not the only one which runs docker as root. I know its not secure but it´s behind a firewall anyways).

Thanks a lot for debugging and your dockerization :)

noevidenz commented 2 years ago

Thanks for the update, glad it's working for you!

I'll make a note in the README for future reference.

noevidenz / multipaper-docker

Nodes don´t create a new world #5