How to integrate with Lazymc

[BaldousHuxley]

First of all, I'd like to say that I'm having a blast with these projects. I'm a fairly new player in the Linux and Docker space so this question might come off obvious, but I'll ask anyway. I'm trying to set up a docker compose build that makes use of both lazymc-docker-proxy (which I found browsing the docs) and a backup container. Thing is, I can't get them to work together. I have basically this setup:

networks:
  minecraft-network:
    driver: bridge
    ipam:
      config:
        - subnet: 172.18.0.0/16

services:
  lazymc:
    image: ghcr.io/joesturge/lazymc-docker-proxy:latest
    networks:
      minecraft-network:
        ipv4_address: 172.18.0.2
    restart: unless-stopped
    volumes:
      - ./server:/server:ro
      - ./docker.sock:/var/run/docker.sock:ro
    ports:
      - "25565:25565"


  mc:
    image: itzg/minecraft-server
    container_name: mc_server
    networks:
      minecraft-network:
        ipv4_address: 172.18.0.3
    labels:
      - lazymc.enabled=true
      - lazymc.group=mc
      - lazymc.server.address=mc:25565
    stdin_open: true
    restart: "no"
    ports:
      - "25565:25565"
    environment:
      EULA: "TRUE"
      TYPE: "MODRINTH"
      MODRINTH_MODPACK: "BYfVnHa7"
      VERSION: "LATEST"
      MEMORY: "8G"
    volumes:
      - ./server:/data
      - /etc/timezone:/etc/timezone:ro
  
  restore-backup:
    image: itzg/mc-backup
    restart: "no"
    entrypoint: restore-rsync-backup
    volumes:
      - ./server:/data
      - ./backups:/backups:ro

  backups:
    image: itzg/mc-backup
    depends_on:
          mc:
            condition: service_healthy
    environment:
      BACKUP_INTERVAL: "24h"
      BACKUP_METHOD: "rsync"
      BACKUP_ON_STARTUP: "true"
      RCON_HOST: mc
      RCON_PASSWORD: "###"
      PRUNE_BACKUPS_COUNT: "7"
      TZ: "###"
      INITIAL_DELAY: 0
    volumes:
      - ./server:/data:ro
      - ./backups:/backups

Starting the services in this configuration throws the following error:

ERROR: for backups  Container "###" is unhealthy.
ERROR: Encountered errors while bringing up the project.

From my understanding, mc-backup needs the server container to be running and healthy at all times in order to successfully back up its data. It also checks for RCON command feedback before executing any custom scripts. If I'm getting this right, it means that lazymc shutting down the server container is basically interfering with the backup service and preventing it from running correctly. Is there any way to make them compatible? Am I just missing something? Thank you in advance.

[itzg]

Yes the backup service is not fully compatible since it needs to use rcon to pause file changes made by the Minecraft server. It has logic to detect pauses server, but doesn't work with lazymc and similar.

I don't recognize the logs you posted so I can't diagnose those specifically. Maybe LazyMC logs? I would have expected the rcon failure logs from the backup container to contain the phrase "Unable to execute".

[BaldousHuxley]

The error message is what pops up after starting the services with docker-compose up -d. Upon running docker ps, the backup container is not listed, so I suspect the depends_on health check fails right away and causes the container to never start.
Also this might be a little wider range, but how would I go making backups to a LazyMC managed server? I thought of removing the health check and adding a script that prompts the container to make a backup only when the server is running, would that work?

[itzg]

That's the general idea 😀 The devil is in the details as they say.

[itzg]

The error message is what pops up

And I still have no clue where/what you're seeing the log message. Maybe message the lazymc maintainer about it that one.

[itzg]

FYI I was simply thinking this exit could be replaced with a condition that checks for a "try again later if down" variable

docker-mc-backup/scripts/opt/backup-loop.sh

Line 667 in e9da207

exit 1

[BaldousHuxley]

Alright I'll see what I can do about it, thank you for the help. I'll try to solve this myself but if I get particularly stuck I might get back here... If anyone feels the need to add anything to the topic they're welcome to.

[dablenparty]

Hi! I actually have been using this with LazyMC for a few months now. For reference, my compose file is here, but I recognize a few issues that I also had:

• You are exposing port 25565 twice; once on the lazymc service and again on the mc service. The README explicitly says not to do this. Even if you get backups working, the stack will not be able to start until you remove the exposed port from the mc service.
• The backups service cannot depend on mc at all if you want to use LazyMC. lazymc-docker-proxy uses SIGTERM to stop the server, which makes the container exit with code 137, so depending on service_completed_successfully or service_healthy will cause the backups container to never start and throw the error that you are seeing.
• Set RCON_RETRIES to -1 and increase the RCON_RETRY_INTERVAL. This means the backups service will ping the servers RCON port indefinitely. When the server is off, the logs get polluted with Failed to connect to RCON server, but when the server is on, it automatically connects to the RCON port and performs backups like normal. It's not ideal, but it works, and you can limit log sizes in your compose file if you feel it's necessary.

I hope this information helps you get your server going and helps @itzg figure out how to tackle this!

[itzg]

Thanks @dablenparty

It sounds like suppressing the extra Failed to connect to RCON server log messages probably would help the most.

[dablenparty]

I think refactoring so that this container runs constantly (like a daemon) would not only solve this issue, but others too. I've been trying to find a way to backup my server on shutdown as well as on startup, but I cannot find a way to do so with this container because it requires the MC server to be running. This requirement has always seemed a little odd to me since most backup solutions I've encountered use daemons, cron jobs, or similar methods to run constantly and shut down their services before running a backup; this container is the opposite, running only when the MC server does by default and not working when the MC server is off. This means I cannot even run on-demand backups (e.g. docker exec backups backup now) unless the server is running, which is counter-intuitive imo. I looked through the code and it seems you use RCON to ensure the server data is saved and won't be written while backing up, but why does that block the backup itself? If the server is off, there is no risk of data being written while the backup is running, which is an ideal backup scenario.

Edit: forgot to make my point. My point is, if this container were to run like a daemon, it won't care if the MC server is on or off and could react to any change in the server lifecycle, not just startup. It would also open the doors to more features, such as backup on shutdown or backing up multiple servers from a single container instance (for example, with mc-router). I'm trying to figure out a custom solution with the Docker Engine API in the meantime.

[itzg]

Great points. It was a fairly arbitrary assumption made early on that most people would only want to do online backups of their Minecraft servers to ensure little to no downtime. That assumption has held for many years now 😃

The good news is that the backup logic can be easily adjusted to optionally skip that assumption and skipping the rcon commands to enable online backups and just jump right to the backup processing.

I'd be happy for a PR that makes some simple changes like that. It could be something like a new env var like ENABLE_OFFLINE_BACKUPS that conditionalizes the rcon operations.