pterodactyl / panel

Pterodactyl® is a free, open-source game server management panel built with PHP, React, and Go. Designed with security in mind, Pterodactyl runs all game servers in isolated Docker containers while exposing a beautiful and intuitive UI to end users.
https://pterodactyl.io
Other
6.7k stars 1.7k forks source link

Error On Force Delete Server #4313

Closed dy1io closed 2 years ago

dy1io commented 2 years ago

Current Behavior

My panel has been running fine since we installed it last year and we have several games running across 5 nodes. Yesterday, I ran into an issue where I needed to force delete a server because the safely delete was not working. When I try to run the force delete, I get a 500 | Server Error message.

This led me to start troubleshooting and look into logs. However, the logs seem to be very out dated, the only logs available are from December 2021, which is not very helpful here. At this point I'm not sure if the logging issue is related or not, but ultimately I'm just trying to delete this server that we no longer need so that we can decommission the node it is on.

I am running the panel on docker, using the ghcr.io/pterodactyl/panel:v1.10.1 image via a docker-compose file. Obviously its possible that I've misconfigured something here, but I assumed that by using the image provided I would be pretty safe in terms of dependencies and configuration. I'll provide my docker-compose file in a comment below to be safe.

I have noticed in the past that anytime one of my nodes loses contact with the panel I cannot force delete a server. I noticed in #3666 that GMP needed to be installed, so I connected to the container, installed it, and restarted the container. That didn't solve the problem, so I pulled down a fresh copy of the image.

I posted this on the Discord as well because I'm not sure if this is a bug or something I've done wrong, but I haven't received any responses to it yet. Any help on this is greatly appreciated and I'm happy to provide any other info or logs as requested, but as stated the default logs directory is not very helpful in this case. Sorry for the book, hopefully all the detail is helpful in helping me. Thank you!

Expected Behavior

Be able to force delete a server.

Steps to Reproduce

  1. Run the panel using the official docker image
  2. Have a server you want to delete
  3. Safely delete fails or the node is offline
  4. Try to force delete
  5. Error message 500 | Server Error

Panel Version

1.10.1

Wings Version

1.6.4

Games and/or Eggs Affected

No response

Docker Image

ghcr.io/pterodactyl/panel:v1.10.1

Error Logs

See above, logs not available

Is there an existing issue for this?

dy1io commented 2 years ago

Here is my docker-compose file as promised.

version: '3.8'
x-common:
  panel:
    &panel-environment
    APP_URL: <redacted>
    # A list of valid timezones can be found here: http://php.net/manual/en/timezones.php
    APP_TIMEZONE: "UTC"
    APP_SERVICE_AUTHOR: <redacted>
    # Uncomment the line below and set to a non-empty value if you want to use Let's Encrypt
    # to generate an SSL certificate for the Panel.
    LE_EMAIL: <redacted>

#
# ------------------------------------------------------------------------------------------
# DANGER ZONE BELOW
#
# The remainder of this file likely does not need to be changed. Please only make modifications
# below if you understand what you are doing.
#
services:
  database:
    image: mysql:8.0
    restart: always
    command: --default-authentication-plugin=mysql_native_password
    volumes:
      - db:/var/lib/mysql
    environment:
      MYSQL_DATABASE: "panel"
      MYSQL_USER: "pterodactyl"
      MYSQL_PASSWORD: ${MYSQL_PASSWORD}
      MYSQL_RANDOM_ROOT_PASSWORD: "true"
  cache:
    image: redis:alpine
    restart: always
  panel:
    image: ghcr.io/pterodactyl/panel:v1.10.1
    restart: always
    ports:
      - "80:80"
      - "443:443"
    links:
      - database
      - cache
    volumes:
      - nginx:/etc/nginx/http.d/
      - ssl:/etc/letsencrypt/
      - ./data/logs/:/app/storage/logs
      - ./data/var/:/app/var/
    environment:
      <<: [*panel-environment]
      DB_PASSWORD: ${MYSQL_PASSWORD}
      APP_ENV: "production"
      APP_ENVIRONMENT_ONLY: "false"
      CACHE_DRIVER: "redis"
      SESSION_DRIVER: "redis"
      QUEUE_DRIVER: "redis"
      REDIS_HOST: "cache"
      DB_HOST: "database"
volumes:
  ssl:
  nginx:
  db:
networks:
  default:
    ipam:
      config:
        - subnet: 172.20.0.0/16

MYSQL_PASSWORD is provided via a .env file.

dy1io commented 2 years ago

This issue is caused by incorrect permissions inside the container. Solution is in #4330