gilesknap/k3s-minecraft

Minecraft servers managed in a lightweight Kubernetes cluster

k3s-minecraft's Issues

chmod: changing permissions of '/data': Operation not permitted

chmod: changing permissions of '/data': Operation not permitted
[init] Running as uid=1000 gid=1000 with /data as 'drwxrwxrwx 2 0 0 4096 Feb 7 14:30 /data'
[init] Resolved version given 1.19.3 into 1.19.3 and major version 1.19
[init] Resolving type given VANILLA
[init] Downloading 1.19.3 server...

Pod stuck in CrashLoopbackoff state

As I stated above pod is stuck.
Env:
k3s version : 1.20.15
nodes:
2 raspberry pi 4

My config:
here

k8s-mc script help

ubuntu at omega in ~/Documents/k3s-minecraft-server on main
$ k8s-mclist
NAME   MODE   VERSION   SERVER   RUNNING
error: array index out of bounds: index 22, length 7

get the above error when i try to list my running mc servers. have no idea how to exec into them and run commands without doing this first as i dunno what the names are.

Kubernetes cluster unreachable and crash loop error.

This happens when I try helm installing the server. I tried installing and uninstalling k3s. I tried https://stackoverflow.com/questions/63066604/error-kubernetes-cluster-unreachable-get-http-localhost8080-versiontimeou

I solved it yesterday(I think it was a combination of the above two). And the server went into a crash loop error. Need help

K3s server sqlite backup

For https://github.com/gilesknap/k3s-minecraft/tree/main/useful/deployed/backup-sqlite, I used the following for taking a backup.

  command:
    - /bin/sh
    - -c
    - apk add sqlite; cd /server; time tar czf /backup/k3s-server-backup-$(date +%F:%R).tgz --exclude *.sock --exclude db . && time sqlite3 db/state.db .dump | gzip -c > /backup/k3s-server-db-dump-$(date +%F:%R).gz && time sqlite3 db/state.db ".backup '/backup/k3s-server-db-backup-$(date +%F:%R).sql" && time find /backup -type f -mtime +60 -delete;

This takes two types of sqlite backup, one a SQL dump, another a DB page by page backup. I am not sure if the drastic decrease in size after restoring the .dump version is actually correct. So, to be on the safer side, I am doing both forms of backups and raised an issue at k3s-io/k3s#5219

To restore,

cd /var/lib/rancher/k3s; mv server server.old; mkdir -p server/db; cd server
tar -xzf k3s-server-backup-XXX.tgz

zcat k3s-server-db-dump-XXX.gz | sqlite3 db/state.db
# OR
cp k3s-server-db-backup-XXX.db db/state.db