Alloc

That output you posted is the normal one you get when you start up 7dtd. I would still suggest using the scripts, start-stop-daemon should not be a problem as I included the required source in the archive just for this purpose. If there's something wrong with compiling it we can figure it out together

Could you send me a copy of the XML (you can blank out steamids)?

Hm, might be the same problem as I saw before ... I assume you are using a version of the scripts prior to v.22? If so please update and delete the players.xml (or at least clean it up manually). Might also be related to the Telnet thread having crashed. Will try to add some checks in there. /EDIT: Nope, should not be a problem Regarding Q2: I think this only happens when the Telnet thread crashed so shutdown does not work. Can't do anything about it as that's a bug in the game itself.

Seconds You don't want the script to block for hours or even minutes. Should never be greater than like 3sec. And only be required for stuff like entity querying as you have to wait for the output to be complete before killing the connection.

Just noticed you put /bin/sh in the shebang ... Please try it with /bin/bash as quite a lot of things in the scripts require a bash.

Hm, ok ... will run a test myself in a few minutes, but it really should work ...

Touch does set the exec-flag on a file, it only changes the modification time. You have to run chmod +x filename.sh to make it executable.

Did you mark the script as executable?

Nope, the hooks are called whenever the events occur, so no need to restart.

Ah, sorry, there's an error in the documentation. All hooks go to a folder called "hooks" in SDTD_BASE. So the path for the hook should be: /home/sdtd/hooks/playerConnect/bemVindo.sh Also in your screenshot it looks like there's an empty line before the shebang which should not be the case (even though this probably won't cause a problem).

Hmz, should really update this part of the scripts ... Try this: #!/bin/sh . /usr/local/lib/7dtd/common.sh checkRootLoadConf telnetCommand $1 "say Hello to $4"

H3llghost is almost right ... the first character being a shebang of course ... #!/bin/sh . /usr/local/lib/7dtd/common.sh telnetCommand $1 "say Hello to $4"

Sorry, but I did not get what you mean by "when it starts to get too server logs".

Ah ... can't help you with this one, never used it as I had some trouble with it when it was first released

Can you be a bit more specific? I.e. what did you do exactly and what's happening then?

Easiest way: . /usr/local/lib/7dtd/common.sh telnetCommand <sessionName> "say Hello" You can also decrease the time the script waits after sending the message, should not matter for using "say": . /usr/local/lib/7dtd/common.sh telnetCommand <sessionName> "say Hello" 0.3 Regards, Chris

Wonder how it could ignore CPU affinity if set for all threads ... Unfortunately I can't do much about such issues, but just as a note: Haven been playing on a server the last days with up to 5 players being online concurrently. No crash, no other problems, CPU load on 4 cores between 40% (2 players) and almost 200% (i.e. two cores almost completely busy) (5 players) but even than it was running fine.

Looks like downloading 7dtd itself did not work. Try rerunning "7dtd.sh updateengine".

Hm, ok, that should not be any problem. Thought it might be that in some locales the server starts but some threads could run into problems with data if the locale is a bit weirder Please tell us if setting the CPU affinity does have any (hopefully positive) effect on performance ,)

Ok, seems to work. You have to edit line 34 of /usr/local/lib/7dtd/commands/start.sh. It should currently start with: LD_LIBRARY_PATH=$SDTD_BASE/linux_files $SSD --start $SSD_PID $SSD_DAEMON $SSD_USER --chdir $SDTD_BASE/engine --exec $SDTD_BASE/engine/7DaysToDie.x86 -- $OPTS ... change it to: LD_LIBRARY_PATH=$SDTD_BASE/linux_files/x86 $SSD --start $SSD_PID $SSD_DAEMON $SSD_USER --chdir $SDTD_BASE/engine --exec /usr/bin/taskset -- -c 0 $SDTD_BASE/engine/7DaysToDie.x86 $OPTS ... The "-c 0" right in front of the 7dtd.x86 is the affinity list, use whatever you like there.

Hm, why 0,4? As you seem to have only 4 cores (at least htop only shows 4 in your screenshot) the highest number would be 3 You might want to try to run "taskset -acp 0,3 <pid>" instead where -a makes it set affinity also for all child threads. Wonder why 7dtd is starting this many threads at all though ... "listthreads" only shows 8 for me while there's roughly 30 threads running. Just some random thing: what locale is your server running? EDIT: You would have to edit /usr/local/lib/7dtd/commands/start.sh line 34. Not sure though if CPU affinity is inherited by new threads started from a process. Testing and will report back with more details

Hm, wonder how it even could use so many cores as I would assume that most threads can't even be that CPU heavy (e.g. the Telnet thread, chunk saving). I gave my games VM only 2 cores anyway so I did not notice this before If you want to try to force it to a set of given cores only you could try to use taskset: http://xmodulo.com/2013/10/run-program-process-specific-cpu-cores-linux.html Regards, Chris

Those are "normal". They appear on some systems, do not know the exact reasons but they also don't seem to matter anyway Hm, looks like it's somewhat different for everyone. At least there were reports it's running ok. Unfortunately yes, the account has to own 7dtd. If not you would not even need to enter any account data at all This might change in the future if TFP release a server only build which could be downloaded with anonymous access but that's not for sure. Regards, Chris

Glad it works. Will add this soon, though I'll have to make sure that the selected locale does actually exist on the system @Elendar: Thought something like this was the culprit. Wonder though why it does work with German locales, as we do have the same decimal notation o.O

@Ribesg: Looks like it indeed is a problem with your locale. I.e. some string parsing function seems to fail because it uses a French interpretation of something that just isn't stored the way you would in French. Judging from the errors it's about parsing doubles. Please try the following: Open /usr/local/lib/7dtd/commands/start.sh in an editor. Go to line 34 which should be: LD_LIBRARY_PATH=$SDTD_BASE/linux_files $SSD --start $SSD_PID $SSD_DAEMON $SSD_USER --chdir $SDTD_BASE/engine --exec $SDTD_BASE/engine/7DaysToDie.x86 -- $OPTS > $(getInstancePath $1)/stdout.log 2>&1 Add "LC_CTYPE=C.UTF-8 LC_NUMERIC=C.UTF-8 LC_ALL=C.UTF-8" so it looks like: LD_LIBRARY_PATH=$SDTD_BASE/linux_files LC_CTYPE=C.UTF-8 LC_NUMERIC=C.UTF-8 LC_ALL=C.UTF-8 $SSD --start $SSD_PID $SSD_DAEMON $SSD_USER --chdir $SDTD_BASE/engine --exec $SDTD_BASE/engine/7DaysToDie.x86 -- $OPTS > $(getInstancePath $1)/stdout.log 2>&1 And start the instance again.