Right now, the only provided mechanism for running the server is some bash script doing weird stuff.

By extracting the forge update logic into its own script file, we can isolate / simplify the server-start.sh script, but we can go further and make a systemd unit file to have an efficient and reliable server-side server daemon.

The following example I'm providing for both the forge-setup.sh part (which is a pieced-together script I made to have the bare functionality ready right away) and the enigmatica.service part is an example I'm using on a private setup, and they are by no means perfect, but I would consider them a decent base to expand on to provide some sane defaults in terms of running / hosting.

forge-setup.sh

#!/usr/bin/env bash

trap 'rm -f /tmp/installer.jar' INT QUIT TERM EXIT

URL="https://files.minecraftforge.net/maven/net/minecraftforge/forge/1.16.5-36.0.10/forge-1.16.5-36.0.10-installer.jar"
TARGET=minecraft-server.jar

wget -O /tmp/installer.jar $URL
java -jar /tmp/installer.jar --installServer

enigmatica.service

[Unit]
Description=Enigmatica 6 Server
After=network.target

[Service]
WorkingDirectory=%h/enigmatica
ExecStart=/usr/bin/java -Xmx4G -server -XX:+UnlockExperimentalVMOptions -XX:+ExplicitGCInvokesConcurrent -XX:+OptimizeStringConcat -XX:+UseAdaptiveGCBoundary -jar forge-1.16.5-36.0.10.jar nogui

Recommended steps to take towards making this unit file better would be to parameterize the jar, e.g. by using a systemd unit template (which would produce something like systemctl --user start [email protected]), or use an environment file stored in ~/.config to configure some of the arguments (e.g. the "MAX RAM", currently hardcoded to 4 GB).

Thanks for the suggestion. My understanding for this sort of thing is lacking at best, and I don't think it would be wise for me to add something I don't really understand. How would users benefit from this?

Setting up a durable server (e.g. on a barebones server / VPS) can be a bit tricky depending on the user's knowledge, and systemd (shipped with the vast majority of linux systems, especially server-side) is a reliable daemon manager, made to do exactly what the server-start.sh does, but in a clean and reliable way.

Providing a base example configuration file for that mechanism is, IMHO, a better option than providing a pretty dense and hacky script.

Providing a base example configuration file for that mechanism is, IMHO, a better option than providing a pretty dense and hacky script.

Good point 😄

Could you perhaps make a PR with these additions?

Not right now, because I'm still fiddling with it (ie stabilizing) and dealing with other stuff IRL, but that has been noted for later on, once I get some time.

My server regularly crashes after a few minutes left running so there's something weird going on that I must investigate when I get the time, but not right now.

I see, fair enough - But perhaps down the line?

Yes, that's what I tried to convey with my message. Once I have something of decent quality, I'm gonna try to PR it into the repo, while maybe adding another PR for the wiki, to document the systemd-based setup.

Excellent, I'll look forward to that then :)

https://gist.github.com/Zyian/2572a3f8ccf88dde7921c1a1c11b40b1
This is what I've been using for my systemd service files (with the source where I got it), it has some configuration for securing down the server itself.

Gist

A systemd unit file for a minecraft server (from: https://teilgedanken.de/Blog/post/setting-up-a-minecraft-server-using-systemd/ ) change $password

A systemd unit file for a minecraft server (from: https://teilgedanken.de/Blog/post/setting-up-a-minecraft-server-using-systemd/ ) change $password - minecraft.service

I'm gonna close this due to lack of activity.