Thanks a lot! This was very informative.
Actually, I should have read the whole topic before using the new script.
Anyways, what's the best way for excluding some files/directories?
For example, the Dynmap directory takes a lot of space, so I would like to exclude that one(using fullrender instead then backing it all up).
And what would be a good cloud hosting company, and the right way to sync my backup?
I have no X-server installed on my server, so I'm looking for a text based solution.
I configured my Dynmap to output the map data to a directory outside of the minecraft folder so I wouldn't have to deal with this.
To exclude something from the backup, you will want to add an option to the rdiff-backup command in the minecraft_server script
Details about excluding files and directories are here http://www.nongnu.or...es.html#exclude
Just replace some/folder/path with your Dynmap directory in the worlds/worldname/ directory.
The FILE SELECTION in the rdiff-backup manual contains more information on what the --exclude option can be.
I think that I found a easy way to fix the screen issue
.... You just need to add "chmod o+rw $(tty)" before screen start in the displayScreen() function. Additionally, You could add another chmod to remove the permissions when you detach
<snip>
Thanks for the patch! Sorry for the delay in incorporating it, I don't check this thread all that often any more.
I just uploaded a new version of the script that fixes the detection of missing programs. Error messages should now be correctly displayed if you are missing something important.
I just uploaded a new version of the script that fixes the detection of missing programs. Error messages should now be correctly displayed if you are missing something important.
Yep, Screen is installed. I'll try it again with this new version of the script.
getMOTD() {
local MOTD_SUMMARY
MOTD_SUMMARY=""
if [ -e $MOTD ]; then
MOTD_SUMMARY=$(head -n 1 $MOTD | $PERL -ne '$_ =~ s/§[0-9a-fA-F]//g; print;')
fi
echo $MOTD_SUMMARY
}
The reason that color codes do not work, is because getMOTD strips the codes out before writing it to server.properties
getMOTD() probably needs to return 1 when the motd.txt file does not exist.
On another note, I modified mine to allow per-world motd files minecraft/worlds/<worldname>.motd
I can provide a patch when I'm done handling home server issues.
I warn you, it's ugly and might not work for you. I've been trying to figure out a way to make this a bit more configurable, but I have't been able to spend much time on it.
I'm using this to help run my gaming community's Minecraft server. I've also modified the everloving snot out of it.
Some of the changes thus far:
1. Changed the Java launch code to allow adding customized start parameters without making a command line that Java will hate. Since a Minecraft server does weird things with/through Java, a good parameter set can make a server fly. (This was doable by hand in the original script - I just added a couple variables and moved things around so the resulting command-line would be syntactically correct.)
2. Modified the mirroring code to only relocate the world files to ramdisk (/dev/shm) instead of trying to mirror the whole server. If you run Dynmap, you will not be able to realistically do a full-server mirror as Dynmap's mapping tileset will be bigger than your server's world files. The modified version automagically renames the original directory as needed, creates and removes symlinks to redirect the server to the relocated world files, and syncs by saving memory to mirror before doing a write to physical disk. Still to do: make it smart enough to know when the world won't fit in the mirror area (e.g., your world's too big to mirror to ramdisk).
3. Changed the backup system to use tar to make a single archive file of the world files only, instead of using rdiff-backup to make an incremented mirror of the entire server. One, again Dynmap comes into play as the motivation for doing this, as a 3GB world may have a 5GB Dynmap tileset made up of a bazillion tiny files, and that just kills storage and makes for absurdly time-consuming backups. Two, by making a .tar.gz, archive file, you have a big but downloadable file that can be stored offsite, whereas rdiff-backup isn't really meant for that outside of networked backups. Runs great from cron - I have it set to make a new archive every 6 hours. (Also included: automatic removal of archive files over X days of age.)
4. Added a whole-server backup archive command, which does what #3 mentions but to the entire server. Ideally, this would be good to run once after each server update and then just do the world-files-only backup in between.
5. Added a "powercycle" command, which basically combines "restart" with "backup." Drops the server, does a world-file backup while it's down (so everything is archived since none of the region files should still be open), then restarts it.
6. Added a "watchstart" command, which basically combines "start" with "screen." This one allows you to watch the server's startup process by switching to the server's screen immediately after sending out the Java startup command. Comes in really handy for catching problem children in your mods directory since the stock script had a 5-second delay between using "screen" and actually seeing the server log.
7. Added a "savetodisk" command, which basically performs a forced flush to physical disk on command. If mirroring is enabled, the map in memory is flushed to the mirror and then copied to physical disk. This one is a great cron victim as well, and especially so when using mirroring.
8. Added a "fullbackup" command to trigger #4, above, and modified the "backup" command to trigger #3.
9. Modified all commands that cause a server stop or restart to have an extended warning period for players, with /say warnings dispatched to players at 60, 30, 15, 10, and 5 seconds before stopping or restarting.
I'm still tweaking the specifics, but once I'm happy it won't melt the machine, segfault something important, and/or destroy some player's last sixteen hours of work, I'll post the changes for everyone's consideration.
1. Changed the Java launch code to allow adding customized start parameters without making a command line that Java will hate. Since a Minecraft server does weird things with/through Java, a good parameter set can make a server fly. (This was doable by hand in the original script - I just added a couple variables and moved things around so the resulting command-line would be syntactically correct.)
I'm curious what these commands are that can make a server fly
2. Modified the mirroring code to only relocate the world files to ramdisk (/dev/shm) instead of trying to mirror the whole server. If you run Dynmap, you will not be able to realistically do a full-server mirror as Dynmap's mapping tileset will be bigger than your server's world files. The modified version automagically renames the original directory as needed, creates and removes symlinks to redirect the server to the relocated world files, and syncs by saving memory to mirror before doing a write to physical disk. Still to do: make it smart enough to know when the world won't fit in the mirror area (e.g., your world's too big to mirror to ramdisk).
I configured Dynmap to save it's data to another folder just to avoid this problem. Also makes the backups way smaller as I don't care if the maps are backed up.
3. Changed the backup system to use tar to make a single archive file of the world files only, instead of using rdiff-backup to make an incremented mirror of the entire server. One, again Dynmap comes into play as the motivation for doing this, as a 3GB world may have a 5GB Dynmap tileset made up of a bazillion tiny files, and that just kills storage and makes for absurdly time-consuming backups. Two, by making a .tar.gz, archive file, you have a big but downloadable file that can be stored offsite, whereas rdiff-backup isn't really meant for that outside of networked backups. Runs great from cron - I have it set to make a new archive every 6 hours. (Also included: automatic removal of archive files over X days of age.)
4. Added a whole-server backup archive command, which does what #3 mentions but to the entire server. Ideally, this would be good to run once after each server update and then just do the world-files-only backup in between.
5. Added a "powercycle" command, which basically combines "restart" with "backup." Drops the server, does a world-file backup while it's down (so everything is archived since none of the region files should still be open), then restarts it.
This script used to do tar.gz backups, but I felt that baking up server this way was an unnecessary waste of HD space when used on the same system. I figured that incremental backups were more efficient use of space. When releasing your modification, I would suggest leaving rdiff-backup as the main backup and add back the ability to backup with tar.gz. The backup command already does a full backup, but it does make those backups in several folders. Good idea to have a way to grab all and save.
6. Added a "watchstart" command, which basically combines "start" with "screen." This one allows you to watch the server's startup process by switching to the server's screen immediately after sending out the Java startup command. Comes in really handy for catching problem children in your mods directory since the stock script had a 5-second delay between using "screen" and actually seeing the server log.
7. Added a "savetodisk" command, which basically performs a forced flush to physical disk on command. If mirroring is enabled, the map in memory is flushed to the mirror and then copied to physical disk. This one is a great cron victim as well, and especially so when using mirroring.
Doesn't this command already exist? '/etc/init.d/minecraft sync [world]' (world is optional)
8. Added a "fullbackup" command to trigger #4, above, and modified the "backup" command to trigger #3.
9. Modified all commands that cause a server stop or restart to have an extended warning period for players, with /say warnings dispatched to players at 60, 30, 15, 10, and 5 seconds before stopping or restarting.
I'm still tweaking the specifics, but once I'm happy it won't melt the machine, segfault something important, and/or destroy some player's last sixteen hours of work, I'll post the changes for everyone's consideration.
I'm eager to see the script!
I also think as this point we should pool our ideas into a github repository or something similar. What do you think?
Also I kinda talk like I invented this script, I only came up with the rdiff-backup portion, thats why I refer to this part as mine.
I'm curious what these commands are that can make a server fly
Well, step one is "unhook server" and step two is "chuck the blasted thing out the window"... They fly pretty well, albeit in a parabolic ballistic trajectory...
In all seriousness, though, the principal command set for Minecraft servers basically involves customizing memory usage and garbage collection, setting SSE for the processor in the machine, enabling large-page support on systems with the RAM to handle it, etc. The params I'm using on Ubuntu 13.04/Java 7/AMD Bulldozer are:
(The commented-out line adds remote connection support for using VisualVM to run profiling and debugging against the Java VM.) The rest basically cranks the VM up a few notches. Experimentation is, of course, required, as the specific parameters and param settings are usually machine-specific, but with this combo our Feed The Beast Ultimate 1.1.2 server pretty much stays at 20.0 TPS with eight people running a shockingly large number of machines at the same time.
Note that although there's already a $SERVER_ARGS variable, I added $SERVER_CONFIG - this is because Java does expect some commands to come in a specific order or it'll throw a "bad command line" error and pout in a corner, and generally speaking, the garbage collection and memory usage stuff needs to come before the jar name.
I configured Dynmap to save it's data to another folder just to avoid this problem. Also makes the backups way smaller as I don't care if the maps are backed up.
That's also a good solution. I prefer to keep everything in one root where possible, but that's just me.
This script used to do tar.gz backups, but I felt that baking up server this way was an unnecessary waste of HD space when used on the same system. I figured that incremental backups were more efficient use of space. When releasing your modification, I would suggest leaving rdiff-backup as the main backup and add back the ability to backup with tar.gz. The backup command already does a full backup, but it does make those backups in several folders. Good idea to have a way to grab all and save.
Incremental mirroring is indeed far more efficient. However, I have more than one admin and the machine is at work on a business broadband connection so I need to be able to remotely administer it (which I do via RDP/SSH/SFTP over VPN), and allow my admins to do the same without having to give them an uncomfortable amount of filesystem access (e.g., SSH). Remote offsite backup capability is thus basically a requirement. In that context, tarballing the backups makes more sense.
I did comment out and preserve the original rdiff-backup code, though, and nothing says I can't make it an either/or/both option that can be selected via setting a variable. In fact, this would probably be the way to roll for this, so each admin can use whatever approach best suits their situation.
Nice idea
Personally, I like to watch the startup sequence in case something drops a load in its pants and needs to be addressed. That addition sure makes this easier.
Doesn't this command already exist? '/etc/init.d/minecraft sync [world]' (world is optional)
It does. I just extended it a bit to make it work with my other changes.
Good idea.
Gives 'em enough time to scream about something cooking in the stove, etc. My reply is essentially "sorry, it's autofiring at this point - better grab your stuff outta the machine!"
I'm eager to see the script!
I also think as this point we should pool our ideas into a github repository or something similar. What do you think?
Since this thing seems to be taking on a life of its own as a big collaboration, setting up a repo might not be a bad idea.
And all the more so since I'm sniffing around at using Apache/PHP to make a web frontend for it...
Also I kinda talk like I invented this script, I only came up with the rdiff-backup portion, thats why I refer to this part as mine.
And I came along and messed everything up, without an ounce of remorse!
Well, step one is "unhook server" and step two is "chuck the blasted thing out the window"... They fly pretty well, albeit in a parabolic ballistic trajectory...
ROFL, that's one way to do it. I've had the opportunity to do just this with my home server. The power supply decided to fry the mobo, ram, and 2 drives.
In all seriousness, though, the principal command set for Minecraft servers basically involves customizing memory usage and garbage collection, setting SSE for the processor in the machine, enabling large-page support on systems with the RAM to handle it, etc. The params I'm using on Ubuntu 13.04/Java 7/AMD Bulldozer are:
(The commented-out line adds remote connection support for using VisualVM to run profiling and debugging against the Java VM.) The rest basically cranks the VM up a few notches. Experimentation is, of course, required, as the specific parameters and param settings are usually machine-specific, but with this combo our Feed The Beast Ultimate 1.1.2 server pretty much stays at 20.0 TPS with eight people running a shockingly large number of machines at the same time.
Note that although there's already a $SERVER_ARGS variable, I added $SERVER_CONFIG - this is because Java does expect some commands to come in a specific order or it'll throw a "bad command line" error and pout in a corner, and generally speaking, the garbage collection and memory usage stuff needs to come before the jar name.
WOW, I didn't know that the Java runtime had that many options, guess I got some research to do.
Incremental mirroring is indeed far more efficient. However, I have more than one admin and the machine is at work on a business broadband connection so I need to be able to remotely administer it (which I do via RDP/SSH/SFTP over VPN), and allow my admins to do the same without having to give them an uncomfortable amount of filesystem access (e.g., SSH). Remote offsite backup capability is thus basically a requirement. In that context, tarballing the backups makes more sense.
I did comment out and preserve the original rdiff-backup code, though, and nothing says I can't make it an either/or/both option that can be selected via setting a variable. In fact, this would probably be the way to roll for this, so each admin can use whatever approach best suits their situation.
Personally, I like to watch the startup sequence in case something drops a load in its pants and needs to be addressed. That addition sure makes this easier.
Same here, in some cases (like starting FTB, it likes to break sometimes).
I've been doing this the hard way, I can't believe I didn't think of this.
As a quick heads-up, I'm working on adding per-instance jar support, with individually customizable settings. (Read: Edit a config file for each instance to set things like memory, java start parameters, server jar locations, etc.) If it works as desired, it gets added to the overall "thing."
EDIT:
- Added per-instance configuration customization. Each world gets its own <world>.conf file that contains variables for jar, jar download location, Java startup parameters, etc. This permits the script to use multiple jars, and allows things like having FTB Ultimate and Tekkit servers on the same machine.
- Added the option to use either rdiff-backup or archive-file (*.tar.gz) creation, or both. Want offsite backups? Want local incremental mirroring? Want both?
- Added a more complete help display - run the script without any commands for a list of commands and their parameters and what they do.
- Redid many of the comments to clarify what does what, clean up little language snafus (since I'm a rabid grammar Nazi with OCD), and make things more readable. Also included with this was the addition of credits (e.g., a link to this thread), installation instructions, commands, and a few suggestions for getting the most out of the script (read: basically a stripped-down version of the first post in this thread).
Since my setup doesn't use all of the functionality of the script (my server's world files are too big to fit on the ramdisk Ubuntu creates) I might have to post a beta of it (wasn't this always a "beta"?) so folks can help bugfix, as I'm quite sure something will need to be unbroken.
I have a working server using a per-server configuration system, so the script will support running multiple Minecraft versions. I have to work a few kinks out of one last command, then I think I'll be ready to post my variant of the script somewhere so everyone can grab and test and find bugs and spam my PM box with angry messages and what-not. I have a Git account and some open-source stuffs posted already, so unless there's a reason to do otherwise (read: if you have a problem with this, please let me know ASAP!) I'll just use my git repo.
On a side note, do we all wanna leave this as public domain, or change the license? I like the Creative Commons: Share-Alike/By-Attribution license myself (as it allows free use but recognizes the rights of contributors, requires the sharing of any changes, and requires crediting contributors), but will leave it as P.D. unless the contributors to the script can reach a quorum on something else.
Nice, I started on something like that for myself but never got around to completing it.
If you look back a few pages, you can see my horrible horrible code that allows my server to run multiple server jars.
I never got around to finishing it up since life happens. The code I had before was mainly a stop-gap fix to address my need for multiple server jars. Currently I am running 2 versions of Feed-the-Beast, a couple 1.4.7 vanilla worlds, and some 1.5.2 worlds.
I set up my own git repo some time ago but since you are further along I could just join yours, that is of course if you don't mind.
My username is zanix on github.
As for a license, I thing we need the original author to agree on a license or non at all. As for my vote, I would rather have some sort of license and I feel CC is a good choice.
Since my setup doesn't use all of the functionality of the script (my server's world files are too big to fit on the ramdisk Ubuntu creates) I might have to post a beta of it (wasn't this always a "beta"?) so folks can help bugfix, as I'm quite sure something will need to be unbroken.
I think the ability to allow only certain worlds to run on RAM disk would be a good idea.
As for beta testing, I usually do all my edits on a virtual box with roughly the same setup as my live server. Makes for a great beta testing environment.
I think the ability to allow only certain worlds to run on RAM disk would be a good idea.
As for beta testing, I usually do all my edits on a virtual box with roughly the same setup as my live server. Makes for a great beta testing environment.
I usually do virtuals for development but my principal development environment is Windows, and thus I don't have the setup to do so in Linux. The only box I have with Linux on it is the live server.
On a side note, I moved mirroring to per-server and added another command: scheduled-restart. Cron it and it'll simply do a scheduled restart of a given server instance, announcing the pending restart to players at 10 & 5 minutes, then at 60, 30, 15, 10, and 5 seconds before. IOW it's just "restart" with a longer pre-restart delay and more announcements, and is intended specifically to be used to regularly restart a server that gets laggy when run too long.
Download the latest build from Git, as a ZIP file: https://github.com/W...hive/master.zip
Or, create a directory on your Linux machine and clone the repo:
At the bare minimum, you'll need the actual script, minecraft_server, and the world-configuration template file, template.conf. Or, skip template.conf and have the script create a world.conf for your world the first time you try to start it! (Check out ftb_ultimate.conf for a real-world example world.conf for my Feed the Beast Ultimate 1.1.2 server running on Ubuntu 13.04.)
I fully expect there to be bugs, so be sure to make use of the issue reporting system on Git so the bugs can be squished.
Aside: zanix has been added as a contributor - if anyone else wants in, please let me know!
Awesome, I'll get to script writing when I get the chance.
After testing your modifications, I think I'll have a few more ideas to add in.
I've started working on a restore interface that lists the rdiff-backup backups and lets you pick which one to restore from.
I should probably add it as a feature request in the github issue queue...
There have been a few patches and changes to the script.
I think the biggest was my change to the backups. I detailed the usage of them here http://www.minecraftforum.net/topic/121830-multi-world-linux-minecraft-server-control-script/page__st__160#entry17579898
I configured my Dynmap to output the map data to a directory outside of the minecraft folder so I wouldn't have to deal with this.
To exclude something from the backup, you will want to add an option to the rdiff-backup command in the minecraft_server script
Details about excluding files and directories are here http://www.nongnu.or...es.html#exclude
Just replace some/folder/path with your Dynmap directory in the worlds/worldname/ directory.
The FILE SELECTION in the rdiff-backup manual contains more information on what the --exclude option can be.
rdiff-backup manual
Thanks for the patch! Sorry for the delay in incorporating it, I don't check this thread all that often any more.
Do you have Java and screen installed?
If missing:
I just uploaded a new version of the script that fixes the detection of missing programs. Error messages should now be correctly displayed if you are missing something important.
The reason that color codes do not work, is because getMOTD strips the codes out before writing it to server.properties
getMOTD() probably needs to return 1 when the motd.txt file does not exist.
On another note, I modified mine to allow per-world motd files minecraft/worlds/<worldname>.motd
I can provide a patch when I'm done handling home server issues.
Yeah, that works
Doing so would allow for multiple types of servers to run, which would allow for an easier hub server which is what i am making.
It starts here http://www.minecraftforum.net/topic/121830-multi-world-linux-minecraft-server-control-script/page__st__180#entry19280885
Then the next 2 posts from me is the full edited version, and a patch for the patch.
I warn you, it's ugly and might not work for you. I've been trying to figure out a way to make this a bit more configurable, but I have't been able to spend much time on it.
Some of the changes thus far:
1. Changed the Java launch code to allow adding customized start parameters without making a command line that Java will hate. Since a Minecraft server does weird things with/through Java, a good parameter set can make a server fly. (This was doable by hand in the original script - I just added a couple variables and moved things around so the resulting command-line would be syntactically correct.)
2. Modified the mirroring code to only relocate the world files to ramdisk (/dev/shm) instead of trying to mirror the whole server. If you run Dynmap, you will not be able to realistically do a full-server mirror as Dynmap's mapping tileset will be bigger than your server's world files. The modified version automagically renames the original directory as needed, creates and removes symlinks to redirect the server to the relocated world files, and syncs by saving memory to mirror before doing a write to physical disk. Still to do: make it smart enough to know when the world won't fit in the mirror area (e.g., your world's too big to mirror to ramdisk).
3. Changed the backup system to use tar to make a single archive file of the world files only, instead of using rdiff-backup to make an incremented mirror of the entire server. One, again Dynmap comes into play as the motivation for doing this, as a 3GB world may have a 5GB Dynmap tileset made up of a bazillion tiny files, and that just kills storage and makes for absurdly time-consuming backups. Two, by making a .tar.gz, archive file, you have a big but downloadable file that can be stored offsite, whereas rdiff-backup isn't really meant for that outside of networked backups. Runs great from cron - I have it set to make a new archive every 6 hours. (Also included: automatic removal of archive files over X days of age.)
4. Added a whole-server backup archive command, which does what #3 mentions but to the entire server. Ideally, this would be good to run once after each server update and then just do the world-files-only backup in between.
5. Added a "powercycle" command, which basically combines "restart" with "backup." Drops the server, does a world-file backup while it's down (so everything is archived since none of the region files should still be open), then restarts it.
6. Added a "watchstart" command, which basically combines "start" with "screen." This one allows you to watch the server's startup process by switching to the server's screen immediately after sending out the Java startup command. Comes in really handy for catching problem children in your mods directory since the stock script had a 5-second delay between using "screen" and actually seeing the server log.
7. Added a "savetodisk" command, which basically performs a forced flush to physical disk on command. If mirroring is enabled, the map in memory is flushed to the mirror and then copied to physical disk. This one is a great cron victim as well, and especially so when using mirroring.
8. Added a "fullbackup" command to trigger #4, above, and modified the "backup" command to trigger #3.
9. Modified all commands that cause a server stop or restart to have an extended warning period for players, with /say warnings dispatched to players at 60, 30, 15, 10, and 5 seconds before stopping or restarting.
I'm still tweaking the specifics, but once I'm happy it won't melt the machine, segfault something important, and/or destroy some player's last sixteen hours of work, I'll post the changes for everyone's consideration.
I'm curious what these commands are that can make a server fly
I configured Dynmap to save it's data to another folder just to avoid this problem. Also makes the backups way smaller as I don't care if the maps are backed up.
This script used to do tar.gz backups, but I felt that baking up server this way was an unnecessary waste of HD space when used on the same system. I figured that incremental backups were more efficient use of space. When releasing your modification, I would suggest leaving rdiff-backup as the main backup and add back the ability to backup with tar.gz. The backup command already does a full backup, but it does make those backups in several folders. Good idea to have a way to grab all and save.
Nice idea
Doesn't this command already exist? '/etc/init.d/minecraft sync [world]' (world is optional)
Good idea.
I'm eager to see the script!
I also think as this point we should pool our ideas into a github repository or something similar. What do you think?
Also I kinda talk like I invented this script, I only came up with the rdiff-backup portion, thats why I refer to this part as mine.
Well, step one is "unhook server" and step two is "chuck the blasted thing out the window"... They fly pretty well, albeit in a parabolic ballistic trajectory...
In all seriousness, though, the principal command set for Minecraft servers basically involves customizing memory usage and garbage collection, setting SSE for the processor in the machine, enabling large-page support on systems with the RAM to handle it, etc. The params I'm using on Ubuntu 13.04/Java 7/AMD Bulldozer are:
(The commented-out line adds remote connection support for using VisualVM to run profiling and debugging against the Java VM.) The rest basically cranks the VM up a few notches. Experimentation is, of course, required, as the specific parameters and param settings are usually machine-specific, but with this combo our Feed The Beast Ultimate 1.1.2 server pretty much stays at 20.0 TPS with eight people running a shockingly large number of machines at the same time.
Note that although there's already a $SERVER_ARGS variable, I added $SERVER_CONFIG - this is because Java does expect some commands to come in a specific order or it'll throw a "bad command line" error and pout in a corner, and generally speaking, the garbage collection and memory usage stuff needs to come before the jar name.
That's also a good solution. I prefer to keep everything in one root where possible, but that's just me.
Incremental mirroring is indeed far more efficient. However, I have more than one admin and the machine is at work on a business broadband connection so I need to be able to remotely administer it (which I do via RDP/SSH/SFTP over VPN), and allow my admins to do the same without having to give them an uncomfortable amount of filesystem access (e.g., SSH). Remote offsite backup capability is thus basically a requirement. In that context, tarballing the backups makes more sense.
I did comment out and preserve the original rdiff-backup code, though, and nothing says I can't make it an either/or/both option that can be selected via setting a variable. In fact, this would probably be the way to roll for this, so each admin can use whatever approach best suits their situation.
Personally, I like to watch the startup sequence in case something drops a load in its pants and needs to be addressed. That addition sure makes this easier.
It does. I just extended it a bit to make it work with my other changes.
Gives 'em enough time to scream about something cooking in the stove, etc. My reply is essentially "sorry, it's autofiring at this point - better grab your stuff outta the machine!"
Since this thing seems to be taking on a life of its own as a big collaboration, setting up a repo might not be a bad idea.
And all the more so since I'm sniffing around at using Apache/PHP to make a web frontend for it...
And I came along and messed everything up, without an ounce of remorse!
ROFL, that's one way to do it. I've had the opportunity to do just this with my home server. The power supply decided to fry the mobo, ram, and 2 drives.
WOW, I didn't know that the Java runtime had that many options, guess I got some research to do.
Agreed
Same here, in some cases (like starting FTB, it likes to break sometimes).
I've been doing this the hard way, I can't believe I didn't think of this.
That would be cool, definately would like to collaborate on this as well.
Yup! It's ok though. Nothing like a hack and slash!
EDIT:
- Added per-instance configuration customization. Each world gets its own <world>.conf file that contains variables for jar, jar download location, Java startup parameters, etc. This permits the script to use multiple jars, and allows things like having FTB Ultimate and Tekkit servers on the same machine.
- Added the option to use either rdiff-backup or archive-file (*.tar.gz) creation, or both. Want offsite backups? Want local incremental mirroring? Want both?
- Added a more complete help display - run the script without any commands for a list of commands and their parameters and what they do.
- Redid many of the comments to clarify what does what, clean up little language snafus (since I'm a rabid grammar Nazi with OCD), and make things more readable. Also included with this was the addition of credits (e.g., a link to this thread), installation instructions, commands, and a few suggestions for getting the most out of the script (read: basically a stripped-down version of the first post in this thread).
Since my setup doesn't use all of the functionality of the script (my server's world files are too big to fit on the ramdisk Ubuntu creates) I might have to post a beta of it (wasn't this always a "beta"?) so folks can help bugfix, as I'm quite sure something will need to be unbroken.
I have a working server using a per-server configuration system, so the script will support running multiple Minecraft versions. I have to work a few kinks out of one last command, then I think I'll be ready to post my variant of the script somewhere so everyone can grab and test and find bugs and spam my PM box with angry messages and what-not. I have a Git account and some open-source stuffs posted already, so unless there's a reason to do otherwise (read: if you have a problem with this, please let me know ASAP!) I'll just use my git repo.
On a side note, do we all wanna leave this as public domain, or change the license? I like the Creative Commons: Share-Alike/By-Attribution license myself (as it allows free use but recognizes the rights of contributors, requires the sharing of any changes, and requires crediting contributors), but will leave it as P.D. unless the contributors to the script can reach a quorum on something else.
If you look back a few pages, you can see my horrible horrible code that allows my server to run multiple server jars.
I never got around to finishing it up since life happens. The code I had before was mainly a stop-gap fix to address my need for multiple server jars. Currently I am running 2 versions of Feed-the-Beast, a couple 1.4.7 vanilla worlds, and some 1.5.2 worlds.
I set up my own git repo some time ago but since you are further along I could just join yours, that is of course if you don't mind.
My username is zanix on github.
As for a license, I thing we need the original author to agree on a license or non at all. As for my vote, I would rather have some sort of license and I feel CC is a good choice.
I think the ability to allow only certain worlds to run on RAM disk would be a good idea.
As for beta testing, I usually do all my edits on a virtual box with roughly the same setup as my live server. Makes for a great beta testing environment.
I usually do virtuals for development but my principal development environment is Windows, and thus I don't have the setup to do so in Linux. The only box I have with Linux on it is the live server.
On a side note, I moved mirroring to per-server and added another command: scheduled-restart. Cron it and it'll simply do a scheduled restart of a given server instance, announcing the pending restart to players at 10 & 5 minutes, then at 60, 30, 15, 10, and 5 seconds before. IOW it's just "restart" with a longer pre-restart delay and more announcements, and is intended specifically to be used to regularly restart a server that gets laggy when run too long.
Visit the MSCS repository on Git:
https://github.com/W...erControlScript
Download the latest build from Git, as a ZIP file:
https://github.com/W...hive/master.zip
Or, create a directory on your Linux machine and clone the repo:
At the bare minimum, you'll need the actual script, minecraft_server, and the world-configuration template file, template.conf. Or, skip template.conf and have the script create a world.conf for your world the first time you try to start it! (Check out ftb_ultimate.conf for a real-world example world.conf for my Feed the Beast Ultimate 1.1.2 server running on Ubuntu 13.04.)
I fully expect there to be bugs, so be sure to make use of the issue reporting system on Git so the bugs can be squished.
Aside: zanix has been added as a contributor - if anyone else wants in, please let me know!
After testing your modifications, I think I'll have a few more ideas to add in.
I've started working on a restore interface that lists the rdiff-backup backups and lets you pick which one to restore from.
I should probably add it as a feature request in the github issue queue...