Package Details: minecraft-server 1.21.3-1

Git Clone URL: https://aur.archlinux.org/minecraft-server.git (read-only, click to copy)
Package Base: minecraft-server
Description: Minecraft server unit files, script, and jar
Upstream URL: https://minecraft.net/
Keywords: bash minecraft official script server
Licenses: custom
Conflicts: minecraft-canary, minecraft-server-systemd
Submitter: sorcix
Maintainer: edh
Last Packager: edh
Votes: 164
Popularity: 0.119461
First Submitted: 2010-11-29 15:52 (UTC)
Last Updated: 2024-10-23 19:51 (UTC)

Dependencies (8)

Required by (0)

Sources (2)

Pinned Comments

edh commented on 2016-06-18 18:24 (UTC) (edited on 2021-10-02 08:19 (UTC) by edh)

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; ctrl+b also works). This will detach your input from the server console. The attaching and detaching is done with tmux (previously 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)

[1] https://wiki.archlinux.org/title/Minecraft#Setup [2] https://wiki.archlinux.org/title/Tmux

Latest Comments

« First ‹ Previous 1 .. 6 7 8 9 10 11 12 13 14 15 16 .. 37 Next › Last »

dopsi commented on 2017-06-14 10:09 (UTC)

Since the latest version, the server requires `java-runtime-headless=8` to run (otherwise I get this error : https://stackoverflow.com/questions/43911553/minecraft-1-12-server-does-not-start-linux-external-server)

edh commented on 2017-04-15 16:01 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

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. @sorcix 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. [1] http://www.tldp.org/LDP/Linux-Filesystem-Hierarchy/html/srv.html [2] http://www.tldp.org/LDP/Linux-Filesystem-Hierarchy/html/var.html

sorcix commented on 2017-04-13 07:08 (UTC)

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 (UTC)

@Synthead 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. [1] http://www.tldp.org/LDP/Linux-Filesystem-Hierarchy/html/srv.html

synthead commented on 2017-04-12 14:07 (UTC)

It's a really bad idea to disable and stop the minecraft-server service in the .install script. The user probably wants this, but it's not the Arch Way (tm) to do it this way.

edh commented on 2017-01-10 15:59 (UTC)

@bronze You (your user) cannot view a process which is owned by a different user however root can see everything. If you have the according sudo capabilities you can execute a single command as a different user by using `sudo -u minecraft <command>`. I assume you can construct the necessary command from there. Either way all of the above would have been unnecessary if you would have continued reading the Wiki [1] or if you would have taken a look at the help page ;D The simplest solution to your problem is using the management script: Type `minecraft --help` for a list of available option, spoiler use `minecraftd console` to connect to the console. In order to disconnect, see the pinned comment. [1] https://wiki.archlinux.org/index.php/Minecraft#Server_management_script

bronze commented on 2017-01-10 00:39 (UTC) (edited on 2017-01-10 02:25 (UTC) by bronze)

The minecraft arch wiki mentions "Either way the server is encapsulated in a screen session which is owned by the minecraft user." However, screen -ls didn't return any screens. I checked if screen was running. I did find SCREEN running ps -aux: root 5302 0.0 0.0 23932 2656 ? Ss 07:53 0:11 SCREEN -dmS minecraft /bin/bash -c cd '/srv/minecraft'; java -server ..... How do I "connect" to the screen named "minecraft"? Why is screen written in all caps? [EDIT] I managed to connect to the screen via "su root" and "su minecraft" (user minecraft doesn't have a password). Is that the only way to connect to the screen?