Native Linux server (with management scripts)

Looks like TFP did not explicitly specify how that date should be formatted so it's different in the Linux build. Maybe even depending on the systems locale.With a german locale it looks like this:

Code:
<blacklisted steamID="76561198xxxxxx" unbandate="05.06.2014 01:56:34" />
Ok, so automatic unban just does not work atm (not caused by the Linux engine!): http://7daystodie.com/forums/showthread.php?11220-Does-automatic-unban-work

The format is actually not relevant and both variants seen in this thread work from that point of view, it's just that the 7dtd engine simply does not care about that unban date ;)

Regards,

Alloc

 
Monitored the traffic ... Looks like it's:Source port: Baseport+2 (i.e. 25002 for baseport 25000)

Dest port: 27017 - 27020

Protocol: UDP

Don't know if only one of the dest ports would be enough, but that matches what Valve documents here:

So I would recommend going for dport 27015-27030.

Regards,

Alloc
its steamport 27036

IPV4 UDP 125u Empfangen auf *:27036
 
its steamport 27036
Hm, so the range is even wider ... On my machine it never sent (or received) anything on that port, only on the given range (27017-27020) ;)

Update of the scripts to v13

Added scripts-update detection+install feature so you don't have to download the management scripts manually each time there is an update ;)

 
I had an issue with file permissions. Seems it has used user 1000 which is a different user than sdtd on my system and it has seemingly chowned a lot of things to that user for some reason and messed a bunch of things up until I chowned them back to root. I think these included the /home, /usr, /var and /etc folders as well as the folders used or created by the bootstrap script where it installed files. For example /usr, /usr/local, /usr/local/bin, /usr/local/lib, /usr/local/lib/7dtd were all owned by user 1000. So was the /etc, /etc/cron.d, and the /etc/cron.d/7dtd-backup file and whatever else there was. It's very odd considering that not only is this not the right user but it shouldn't be touching those folders in the first place.

I realize everything probably shouldn't run as root but it seems this script requires it. Luckily I don't really have anything else on this server other then some inactive stuff I was testing before. If it ever ends up not running as root then there are some things in /home/sdtd that are owned by root which may cause issues too but I'm sure that would get sorted out.

So anyway, once I fixed that I created a cronjob to remove old backups. I simply modified the 7dtd-backup cron file that was added and added another cron to it.

Code:
5 * * * * root nice -n 19 find /home/sdtd/backup/* -maxdepth 0 -type d -mmin +1440 -exec rm -rf {} \; > /dev/null 2>&1
Make sure to leave a blank line at the end of the cron file.

It removes any backups that are older than 24 hours. Change the number -mmin +1440 to remove files older than that number of minutes. You just have to make sure to download them before they get deleted in case you ever need them.

I changed the times because I don't like running things exactly at the top of the hour since other cronjobs will often run then and potentially cause some lag. I also added nice to everything to help prevent lag as well.

It might be good to just rsync them off to another server but it might be nice if it compressed them first to save bandwidth and disk space. I tried to add a cron to do this but something in the backup script is conflicting with it. Probably the way you copy the folder and then rsync it. So if it was going to compress it then it would have to be compressed in there somehow which would probably be better anyway. I'm not sure exactly what it's doing there with the rsync parameters but I know the backups work because I used one.

 
Hm, it the scripts do ensure the permissions of some files/folders are set correctly but they should not touch anything outside SDTD_BASE or /usr/local/lib/7dtd (besides the 7dtd-files in bin, etc, cron.d, bash_completion but those are relevant to these scripts only anyway).

The only thing that I could imagine could interfere with other folders could be the un-tar-ing of the mangament scripts. But I never got any problems with that either. Will dig into that though.

Regarding running as root: Basically the scripts could all be made to be runnable by the user for the game itself (i.e. "sdtd" in default installs). But as the user is changed for starting the engine anyway I didn't see much of an advantage in that. Also e.g. updatescripts would not work without root permissions. Also by running as root a lot of stuff could be made root-(write)-only later on (e.g. the whole engine folder if there's nothing left that wants to open files for writing in there) or the backups. This would reduce the risk of the engine damage anything if there was a security hole.

Backups: The backup system requires a few changes anyway as I was going to implement a few limits (ticket 12). I will also include an option to have backups compressed (though that obviously would negate the positive effects of hardlinking stuff ;) ).

Running backups at different priority is a good idea, will add that too :)

As far as transferring backups to other targets: You could write a backup hook for that purpose (see Hooks). This would be run directly after a backup was created and you would get the folder passed as parameter so you could simply compress/rsync it or whatever you want to (compression will be added directly next release, probably later today).

Regards,

Alloc

 
Ah yes, maybe tar is the culprit. That would make sense. Maybe the user is being created the same as what's in the tar file somehow instead of ignoring the user permissions.

Thanks for the other info too. Pretty neat stuff! Can't wait to see what the future holds.

Oh I noticed another thing, in the players.xml file in the instance if the nick has a space in it then it gets cut off at the first space. Not sure if that's intended or what but thought I should mention it anyway.

Thanks again =)

Edit: I noticed it also in the players.log file.

 
Last edited by a moderator:
Hey there,

I had an idea. I think the server gets slightly wonky eventually for whatever reason, but it's alpha so I guess that's to be expected. I don't really know what all exactly but just little things feel different after a restart. So is there some way to do an announcement for auto restarts? I was hoping to setup auto restarts every 6 hours or something so that it gives a series of warnings saying it's about to restart. For example:

The server is restarting in 5 minutes.

The server is restarting in 1 minute.

The server is restarting in 30 seconds.

The server is restarting in 10 seconds.

The server is restarting in 5 seconds.

3

2

1

The server is restarting now!

Then it waits for a small period of time. Then it restarts.

When the server is down it could even optionally do a backup before starting up again or restart the system (if there were kernel updates installed or something) or optionally update things automatically in the future or at least check for updates and optionally send an email if there is an update for this script or for 7dtd or whatever else there happens to be to check for updates for. This could help to automate things a little but give us a chance to manually update if we wanted to so things don't break.

I saw this but it doesn't seem to work quite right for me: http://7daystodie.com/forums/showthread.php?7246-Simple-Status-Script

Anyway, just an idea.

 
Last edited by a moderator:
Just released v.14, added backup options (see the Release Notes).

Also fixed the permissions problem when installing/updating. Shame on me, just did not notice this when testing :(

Oh I noticed another thing, in the players.xml file in the instance if the nick has a space in it then it gets cut off at the first space. Not sure if that's intended or what but thought I should mention it anyway.
Yeah, of course that's intended ;)

No, it's not, never thought about the possibility for a player name to contain spaces. Could you send me a snippet of the output_log.txt containing a "RequestToSpawnPlayer:"-line for such a player?

So is there some way to do an announcement for auto restarts? I was hoping to setup auto restarts every 6 hours or something so that it gives a series of warnings saying it's about to restart. For example:...

Then it waits for a small period of time. Then it restarts.
Hm, one could simply do this by an external script using the functions of the management scripts (i.e. the telnet-interface). Of course I could also add this internally but I think that's too user dependent. Added as ticket 15 for now.

When the server is down it could even optionally do a backup before starting up again ...
Well, this is the ideal usage example for hooks ;) Just write a hook for serverPostStop which executes 7dtd.sh backup.

or restart the system (if there were kernel updates installed or something)
That definitely won't go in the normal release as this is way to much depending on what the server is doing. Should never be done automatically IMHO.

or optionally update things automatically in the future
Again too dangerous. What if an update breaks compatibility in some aspect? The server might not be able to start again until the admin notices.

or at least check for updates and optionally send an email if there is an update for this script or for 7dtd or whatever else there happens to be to check for updates for.
For the scripts this could be done. For 7dtd I already thought about it myself but unfortunately SteamCMD doesn't provide a command to only check for updates but only allows to actually run the update :(

Added as ticket 16 though, might find some way.

I saw this but it doesn't seem to work quite right for me: http://7daystodie.com/forums/showthread.php?7246-Simple-Status-Script
Have never worked with expect myself, but I don't see an obvious reason why it should not work. You could also use the provided function telnetCommand though which basically does the same.

Code:
. /usr/local/lib/7dtd/common.sh
checkRootLoadConf
telnetCommand <instancename> <command> [timeout=1s]
Command would be "lp" or "say Checkout http://your.website.goes.here for server info" in the case of the linked thread.

Regards,

Alloc

 
Released v.15, added checking for newer versions of the engine (see the Release Notes).

For 7dtd I already thought about it myself but unfortunately SteamCMD doesn't provide a command to only check for updates but only allows to actually run the update :(
Heh, it is possible but you have to find out how to do so first. SteamCMD is not as well documented as I would like it to be ;)

Though I am not really checking for updates but instead I compare the buildid of the installed version with the buildid for the latest public branch.

Regards,

Alloc

 
Could you send me a snippet of the output_log.txt containing a "RequestToSpawnPlayer:"-line for such a player?
I sent a PM with this info.

That definitely won't go in the normal release as this is way to much depending on what the server is doing. Should never be done automatically IMHO.
True, only if the machine is completely dedicated to this game and I know exactly what's going on would I get the machine to restart during a game restart if necessary and plus I can easily write a script to do this.

Again too dangerous. What if an update breaks compatibility in some aspect? The server might not be able to start again until the admin notices.
That is definitely a possibility if people were to turn such an option on. Perhaps it could just give notifications that there is an update of some sort. If it could give a notification or an email saying there is an update ready and to click here to apply. I guess to click though you would have to have some sort of web interface control panel thing but that would be another project or layer to this. Doing things manually isn't so bad yet I suppose.

Have never worked with expect myself, but I don't see an obvious reason why it should not work. You could also use the provided function telnetCommand though which basically does the same.
Code:
. /usr/local/lib/7dtd/common.sh
checkRootLoadConf
telnetCommand <instancename> <command> [timeout=1s]
Command would be "lp" or "say Checkout http://your.website.goes.here for server info" in the case of the linked thread.
Oh nice! That should be perfect. Thanks!

 
Release v.16, fixed the playernames with blanks issue.

Perhaps it could just give notifications that there is an update of some sort. If it could give a notification or an email saying there is an update ready
That would be easy to add and I think it would basically be a good thing. Drawback: I have to rely on yet another tool like sendemail in order to do so :(

 
Could those of you who already run the Linux engine report in on how it performs? And if you ran it through Wine on the same environment with the same usage (players) before a "comparison" of how both perfom would be especially nice.

"Performs" as in: CPU usage, memory usage, "felt" performance on client side (lagging zombies etc).

Also please give a few facts about the player count and HW (CPU, RAM).

Would really appreciate it and probably there are others who would too ;)

Regards,

Chris

 
Could those of you who already run the Linux engine report in on how it performs? And if you ran it through Wine on the same environment with the same usage (players) before a "comparison" of how both perfom would be especially nice."Performs" as in: CPU usage, memory usage, "felt" performance on client side (lagging zombies etc).

Also please give a few facts about the player count and HW (CPU, RAM).

Would really appreciate it and probably there are others who would too ;)

Regards,

Chris
Might be good to list how many CPU Cores you have dedicated to that Virtualization if possible, I'm trying to figure out the full specs for a 20 slot server running that headless linux server. I don't think our current 2 Cores, is going to do it most likely need to add more to the VPS. Anyone know minimum specs for a 20 slot?

 
4 cores with 2.67GHz and 4 GB RAM running under wine 32 can take up to 6 players without any lags (cpu load about 2).

More people haven't joined the server yet or leave it instantly (it is a realistic one).

If you are running with wine-64 you need less CPU and less RAM.

 
4 cores with 2.67GHz and 4 GB RAM running under wine 32 can take up to 6 players without any lags (cpu load about 2).More people haven't joined the server yet or leave it instantly (it is a realistic one).

If you are running with wine-64 you need less CPU and less RAM.
Thanks =)

But you haven't tried the native engine to compare with?

 
Could those of you who already run the Linux engine report in on how it performs? And if you ran it through Wine on the same environment with the same usage (players) before a "comparison" of how both perfom would be especially nice."Performs" as in: CPU usage, memory usage, "felt" performance on client side (lagging zombies etc).

Also please give a few facts about the player count and HW (CPU, RAM).

Would really appreciate it and probably there are others who would too ;)
No one else? Thought there were more people running their servers on Linux ... ;)

 
No one else? Thought there were more people running their servers on Linux ... ;)
I would think there is room for improvement in the future since this is just alpha. I have never used it on wine, at least I don't think, just what this script does now.

All I can compare it to is a Minecraft server and it's probably at least 5-10 times more CPU intensive than Minecraft at this point.

Not sure about the RAM usage but I have 32 gigs of RAM and it only takes up about 1.3 gigs so I'm not really worried about that.

I set max players to 10. I've had about 5 on at a time at the very most and haven't noticed any lag or anything but it was using a lot of CPU. Though I'm not sure if I would really be able to tell the difference between lag and a buggy game at this point.

The server is running Ubuntu 14.04 and has 32 gigs of RAM, SSD drives and Intel Xeon E3 1245v2 4 core/8 thread processor.

 
Thanks ryvix, sounds quite ok.

@All:

Just noticed that the update detection does indeed NOT work. Looks like SteamCMD has some private cache of the AppDB so the shown buildid will always be the one when you last downloaded/updated 7dtd :(

Have not found a way to get the current remote buildid yet (and can't even go on testing that now as I updated for testing purposes and now I obviously got the current buildid again ... ;) ).

Will do more tests on the next release.

For those who are already running the latest scripts and want to update 7dtd: Use the --force parameter to update even though the script says there's no update ;)

Regards,

Chris

 
Back
Top