Package Details: minecraft-server 1.12-4

Git Clone URL: (read-only)
Package Base: minecraft-server
Description: Minecraft server unit files, script, and jar
Upstream URL:
Keywords: bash minecraft official script server
Licenses: custom
Conflicts: minecraft-canary, minecraft-server-systemd
Submitter: sorcix
Maintainer: edh
Last Packager: edh
Votes: 123
Popularity: 0.944816
First Submitted: 2010-11-29 15:52
Last Updated: 2017-07-24 17:37

Pinned Comments

edh commented on 2016-06-18 18:24

To get an overview of the available options provided by the management script, be sure to have a look at the help page or read the according section on the ArchWiki article [1].

You can quit the console without shutting down the server by press ctrl+a d (first ctrl+a and after releasing the buttons press d). This will detach your input from the server console. The attaching and detaching is done with GNU screen since it lets you view and type into the console, send single commands to it and keep it alive without a connected user. Take a look at the the command overview at the ArchWiki [2] to get a feel for its power. (@carmelo12341)


Latest Comments

edh commented on 2017-07-24 17:40

Thanks for reporting the bug. I just pushed the necessary changes to fix it.
However I chose to solve it using pure bash instead of xargs and find but it should work just as well.

Avatar commented on 2017-07-24 15:36

I am having issues with removal of old backups with "minecraftd backup" when there are more than one file to remove. I replaced the line with the following and it seems to work better:

find "${BACKUP_DEST}" -mindepth 1 -type f | sort | head -n "$(( BACKUP_COUNT - KEEP_BACKUPS ))" | xargs ${SUDO_CMD} rm

edh commented on 2017-06-14 14:54

I read about it but completely forgot to update the dependency array. Sorry about that.

dopsi commented on 2017-06-14 10:09

Since the latest version, the server requires `java-runtime-headless=8` to run (otherwise I get this error :

edh commented on 2017-04-15 16:01

Upstream only provides a jar file which by default starts a GUI instead of running as a daemon. Personally I think passing down merely a file would provide an unusable package.
Hence I think of the script to be similar to providing a SystemD service where upstream does not. Admittedly the script is lengthier than an ordinary service but the core functionality is the same: start, stop, restart. Despite not feeling comfortable rating its 'Arch-ness' in percent, I still think it complies with the Arch principles.
Merely providing a service without a script would still work but would deny users to connect to the console etc. and thereby limit the original version which is provided upstream. I do not demand that you agree to my reasoning but I hope that you might understand why I chose to keep and enhance the script.

To be honest I though people would care more about the placement in /srv since strictly speaking this is not recommended.

All in all, it seems that the consensus is to keep (respectively tolerate) the script and leave things at /srv.

sorcix commented on 2017-04-15 14:58

Adding scripts that change the way you have to handle a service is not "100% Arch Way". The Arch way is to provide clean packages that resemble upstream. This package makes it harder to manage minecraft servers using configuration management like Ansible, as it works completely different compared to other distro's. (It's required to add an additional service unit, for example, as the default one uses the script.)

Using /srv looks fine according to Arch standards.

@edh: The script was added by a maintainer after me. That said, I don't care about being there, I have worked around it on my servers. But if someone declares this "100% Arch Way" I feel the need to point out that someone is wrong on the internet. ;-)

sowieso commented on 2017-04-13 17:21

In my opinion /srv is totally fine as it is providing a special service via the internet. I wouldn't change that.

As the shell script provides much more features beyond just starting it's obvious that it can not be replaced by systemd. As a service-file is provided to control the shell script, I can't find a problem here. Just see the shell script as the application. 100% Arch Way imho.

As for changing permissions and restarting – I have no strong opinion on it. "The user probably wants this, but it's not the Arch Way (tm) to do it this way." The Arch Way is keep it simple. If there are no technical limitations, this means also keep it simple for the user, not only for the system. Just be sure that there are no untracked files after package removal besides config and /srv/minecraft.

edh commented on 2017-04-13 11:57

Since there seems to be multiple people wanting a more standard package, I will remove the according lines from the install file. Furthermore I would like to discuss whether it makes sense to move the server from /srv [1] to /var/lib [2] simply because /srv is non-standard in Arch.

Please provide constructive feedback instead of referencing an old discussion about sockets. Furthermore I have no idea what your general problem with the script is. It originated from your very own one and has merely been adapted over time.


sorcix commented on 2017-04-13 07:08

This is a horrible package standards-wise anyway, with the whole shell script instead of using systemd properly. If a decent package is important to you, I think you better create an alternative.

edh commented on 2017-04-12 14:51

Though I agree that it probably is not the way most Arch developers do it, I still think it makes sense. Not disabling a service might leave broken symlinks on the filesystem and IMHO it is the job of a packager manager to cleanly remove a package when asked to.
Nevertheless I will do whatever the majority wants to. If people start wandering what is going on, I will remove the according lines.

P.S. the package is "nonstandard" in several ways:
* I remove the minecraft user on un-installation. However you must consider that the ownership of the server root is changed and the user is exclusively used by this package.
* The server root is on /srv which is also unusual. IMHO this is simply where it belongs [1].
No general rule can fit every package and like above I am willing to debate.


All comments