User:M3tal Warrior/Script Bugs & Suggestions

From Minecraft Wiki
Jump to: navigation, search

This page is about reporting bugs in my server scripts. Please sign your contributions, so I can mention you in my script.

How to report a bug[edit]

The report should contain the following information:

  • Used server (Bukkit or Vanilla)
  • Used script (you will know why in time)
  • Operating system (if not an up-to-date Debian Wheezy)
  • Invocation used
  • Server response (if any)
  • Script response (if any)

I don't really need a fix or a subsection provided (at least as long as I'm able to reproduce the bug), but if you feel in the mood I won't bite if you do :)

Since I normally don't delete vital parts of previous scripts without replacing them with something better, I don't see a reason why someone should use old releases. Therefore I won't do fixes for them. Just update, maybe it's already fixed.

Version 1.3[edit]

01/09/2013 - server_control mc_clearlog not functioning as intended[edit]

Server: Vanilla Script: v1.31 OS: Ubuntu 13.04

Some of the wording on the messages this function was intended to cull has changed in Vanilla. Here's a diff patch which adds new lines without removing the old: pastebin . com / GS3UuvZU --caboose684 22:44, 1 September 2013 (UTC)

  • I already know about that, and that you're not really able to change the cleaning routine without getting the nasty security warning. Problem will propably be dealt with the introduction of commandgrid. ATM I'm still thinking about how to do the multiserver environment and - most importantly - the update thereof. Guess you'll have to wait some time still. -- M3tal_Warrior -- 07:27, 2 September 2013 (UTC)
  • Nasty security warning? I'm using those edits in a live environment. Is there something I'm missing? --caboose684 14:32, 2 September 2013 (UTC)
  • Nope, it's just if you update the script without the version number changing, but the files being different - then there should be a security breach warning and the updater being paused for you to investigate. Like, if you do it right now, you get that ;) But like I said, I work on that today, so let's see if it goes as planned. -- M3tal_Warrior -- 05:21, 3 September 2013 (UTC)

17/06/2013 - Issues when using install script[edit]

When trying to install using the new installation script I get the following error after the creation of user account for the minecraft server;

Step 2 - Download scripts & configs ---------------------

Removing files that shouldn't be there anyway, to ensure secure environment... bash: /dev/shm/mc_update.tmp/ Permission denied

Something went terribly wrong during the procedure - can't continue!

  • Used script:
  • Operating system: Debian Wheezy 7.1
Uhm, sry to haven't answered you yet, but I guess you found out yourself: If there's a permission denied somewhere, I'm pretty sure it is because you tried an install previously with some other user. Since you should be root on that machine anyways, just manually delete it. -- M3tal_Warrior -- 21:47, 22 July 2013 (UTC)
Ran into the same issue on Debian Wheezy 7.2. Deleting files from /dev/shm/ from previous installation did not resolve the problem. Changing "bash -c $TEMPPATH/" to "bash $TEMPPATH/" fixes it!
Wow. I have no clue why that doesn't work any longer... It's not that I just wrote that different - every bash invocation uses parameter -c. I'll dig into it. But the installer is atm second issue; first the script has to be v1.4. Would you mind signing your contribs or do you wish to be named as anonymous? -- M3tal_Warrior -- 23:28, 19 October 2013 (UTC)

22/01/2013 - Installer Script Bug[edit]

When trying to set the MAINTAIN_SCRIPT_PATH to a different location, it just repeats the same question again. This happens for any path that I input even the default path. This also happens when I try to set the path for any other file.

  • Used script:
  • Operating system: Ubuntu 12.04

--Dummiboi 07:22, 22 January 2013 (UTC)

Found and (think I) got rid of the bug. Thanks for submitting, you will be named in v1.4. -- M3tal_Warrior -- 15:04, 25 January 2013 (UTC)

Version 1.20[edit]

17/10/2012 - mc_feedback bug[edit]

it could be just that java isn't running quite as fast as it should be on my system, but I found that in order to get any console feedback I needed to add a

sleep 1

line to the mc_feedback function. Otherwise it greps server.log a fraction of a second before the logfile has the relevant info

congrats on getting the server script fully GNU!

--Ben Albon 13:42, 17 October 2012 (UTC)

This isn't a JAVA problem, this is a HDD problem - the new log version isn't written on HDD the time mc_feedback greps it, which I didn't see because I use RAMFS (considerably faster ;)). I'll fix that for 1.3 - I'm already into unstable-alpha :)
Thanks a lot! -- M3tal_Warrior -- 14:08, 17 October 2012 (UTC)
Just so you know, I'm also using RAMFS ;)
Let me know if you want a beta tester for 1.3 --Ben Albon 14:48, 18 October 2012 (UTC)

28/10/2012 - do *nothing*[edit]

Issuing a 'do' command without any arguments causes the server to crash with an ArrayIndexOutOfBoundsException

--Ben Albon 17:43, 28 October 2012 (UTC)

All right, will try to reproduce the bug if I find time to go on bugfixing the new scripts and then add something funny. Thanks a lot! -- M3tal_Warrior -- 22:42, 28 October 2012 (UTC)


04/12/2012 - use of rsync in mc_backup()[edit]

Small suggestion - I would use "cp -r" instead of rsync for a couple reasons:

  • 1. rsync doesn't gain you anything here since the destination doesn't exist.
  • 2. The timedate stamp on the backup directory is always the same as the source with rsync. If you do a normal cp, the timedate stamp is of the backup, which makes it real easy to do a "find -mtime ... -exec..." to remove old backups. As it is, I'll need to put together a script to parse directory names to find the oldest ones.

- Mark Buechler.

Sorry I do answer late, didn't get an email of this change (wonder why, but that's not your problem).
Basicly, I use rsync over cp for various reasons, one being that it's faster (at least when updating a directory, which might occur sometimes even with backup). Second reason is the one you don't like (if I understood you completely): Every file has exactly the timestamp it has on the server at that particular moment, it's a non-modified snapshot of the server. That is intended. However, the timestamp of the directory which contains the backup is that of the backup time.
Honestly I don't really see your problem: The name of the backup directory is exactly that of the time the snapshot was taken, sorted by year-month-day-hour-minute. If you want to kill old backups, you only have to do a rm -r server_2012.11.* to erase every backup made in november. What you might like to see is an easy-erase function within the script which probes for backups older that xxx days. I might take that into consideration for v1.4, if that's of any help. -- M3tal_Warrior -- 15:39, 19 December 2012 (UTC)

01/25/2013 - ability to run/manage multiple servers concurrently[edit]

Suggestion would be to allow the specification of the init.d script name (ie minecraft-survival or minecraft1.5) so that multiple scripts could be run concurrently and manage their own individual servers. This would also require that the scrips keep track of the screen session generated for each server and write only to their own session. This would allow this utility to easily manage a physical server that runs multiple minecraft servers.

- Pagan0ne

You're suggesting a feature that was already planned, but not exactly for minecraft, since with Bukkit and the multiverse plugin you're able to do multiple worlds on one server (and don't have the overhead of whole second server). Initially I thought about that for Tekkit, which is too different to be run simultaneously on one Bukkit server. v1.4 will also be able to work with Bukkit Beta versions, so just sit back and wait until I'm done with my exams and have time to do it :) -- M3tal_Warrior -- 12:13, 29 January 2013 (UTC)

08/06/2013 - 1.6.x Server support?[edit]

I'm wondering if you plan to add support for the new server versions. I'd much rather wait for a new version of your scripts (which are fantastic) than use something else. If you don't plan to support the new binaries though, I'll start checking out my options. caboose684 04:39, 6 August 2013 (UTC)

I'm a little confused - There SHOULD be support for every version of the minecraft server, being it Vanilla or Bukkit (if they're out of the beta state) since the script only checks the commonly used links, downloads the file and does a diff to see if there's any difference between the running server version and the recently downloaded one. After that it decides whether to stop the server, make a backup, replace the binary and fire it up again or just deleting the downloaded file for being just the copy of the already running server. So basicly there shouldn't be need for a script update when the server version changes. You just fire a binupdate, rest is up to Mojang or the Bukkit team.
I am truly sorry there's no v1.4 yet, since I don't have as much time as I would like to have (72 hours a day would be a great start ;)). But if there's a problem with the links I didn't see yet, I'll do a v1.3.1 ASAP. My server is still on 1.5.2 too, since Bukkit isn't done with a proper none-beta-1.6.x yet. (That is only speaking about the productive server. MikeMatrix fires up a 1.6 snapshot now and then to test new Voxel stuff before updating the VoxelBox, but this is with a modified version of my script and totally alpha-testing.) -- M3tal_Warrior -- 15:07, 6 August 2013 (UTC)
Starting with v1.6 of the vanilla server (and client, for that matter), the binaries are version-named. So minecraft_server.jar still points to 1.5.2, and will for the forseeable future. Vanilla v1.6.2 is actually called minecraft_server1.6.2.jar. It appears each version also has its own directory as well. Unfortunately that means your script needs to go looking for that stuff. Maybe grab the latest link from caboose684 15:17, 6 August 2013 (UTC)
I wrote a script to grab that link. Feel free to steal, modify, and not attribute. If I were allowed to post an external link, it would be a pastebin: AvsejuRT caboose684 16:05, 6 August 2013 (UTC)
Got it, quite different to your suggestion, but I guess a little more easy to understand. Just update the script family with a normal update, that should do the trick. You will get a weird error after the scripts are updated, but I didn't get why and it doesn't matter, because isn't written to /etc/init.d anyways. Guess there's a cd wrong somewhere, will check that soon, I think. BTW, how do you like my pop culture references? -- M3tal_Warrior -- 00:41, 8 August 2013 (UTC)
The Mechwarrior bits are the best. Also, `grep -v "^$" commandgrid.conf` was an interesting read. Hey, thanks for the quick turnaround time and keep up the awesome. Your script is badass. caboose684 02:52, 8 August 2013 (UTC)

8/19/2013 - server_control mc_feedback[edit]

  • in server_control mc_feedback use tac instead of cat. Also try a sed script combined together they should speed search up considerably.

tac "$MCPATH/server.log" | sed -n "b main; :branch {s/^$MCNOW/$MCNOW/p; n; t branch; q}; b end; :main /^$MCNOW/b branch :end" | tac

  • Tac is a nice idea, come to think of it, but I don't think there should be a speed issue greping the file, unless you totally don't clean the stuff up now and then. I'll see what springs to mind to smoothen the stuff... and maybe tail is much better to use in that case anyways. Thanks for the input, writing it right now! -- M3tal_Warrior -- 11:28, 30 August 2013 (UTC)

9/10/2013 - Call for Links: Servers[edit]

  • As v1.40 slowly rises from the mist, I ask you to provide links to server apps that one might want to run with the script, so I can add them to the URL list and updater. Since I still have to write a proper website crawler for vanilla, websites will be OK too. Additionally I'd like to announce a name for the update; it will be called the LEGION update. -- M3tal_Warrior -- 16:39, 10 September 2013 (UTC)