Results 1 to 9 of 9

Thread: 7 Days To Die Dedi Fatal Error: Magic Number is Wrong 542

  1. #1
    Scavenger Dox's Avatar
    Join Date
    Jan 2015
    Location
    Eastern US
    Posts
    51
    Rep Power
    0

    7 Days To Die Dedi Fatal Error: Magic Number is Wrong 542

    Hey guys,

    Running a dedicated server on an Ubuntu System 64 19.04. The server worked great for 2 weeks before encountering this issue:

    Code:
    Exception: Magic number is wrong: 542
      at System.TermInfoReader.ReadHeader (System.Byte[] buffer, System.Int32& position) [0x00000] in <filename unknown>:0 
      at System.TermInfoReader..ctor (System.String term, System.String filename) [0x00000] in <filename unknown>:0 
      at System.TermInfoDriver..ctor (System.String term) [0x00000] in <filename unknown>:0 
      at System.ConsoleDriver.CreateTermInfoDriver (System.String term) [0x00000] in <filename unknown>:0 
      at System.ConsoleDriver..cctor () [0x00000] in <filename unknown>:0 
    Rethrow as TypeInitializationException: An exception was thrown by the type initializer for System.ConsoleDriver
      at System.Console.SetEncodings (System.Text.Encoding inputEncoding, System.Text.Encoding outputEncoding) [0x00000] in <filename unknown>:0 
      at System.Console..cctor () [0x00000] in <filename unknown>:0 
    Rethrow as TypeInitializationException: An exception was thrown by the type initializer for System.Console
      at UnityEngine.UnityLogWriter.Init () [0x00000] in <filename unknown>:0 
      at UnityEngine.ClassLibraryInitializer.Init () [0x00000] in <filename unknown>:0 
     
    (Filename:  Line: -1)
    Previously a fresh install FIXED the issue, I simply installed the dedicated server (copied my world and server) to a new directory and it worked great again for about 48 hours. This worked once.

    Things I have tried:
    Using a backup (a clone of the entire dedicated server folder) from when it was working previously.
    A fresh install with my config/admin files preserved (and removed previous installs from steam directory)
    A fresh install without any modifications

    These now all result in the same fatal error.

    A friend mentioned that it could be a 32/64bit conflict, as 7 days dedi only works on the 32bit version, but I figure if this was related, it would have never worked in the first place. I have attached the server log. https://pastebin.com/TYLZ023N

    Any help and advice will be appreciated.

    Edit: Log of it working https://pastebin.com/mhxKHFgL
    Last edited by Dox; 07-14-2019 at 08:24 PM.

  2. #2
    Community Moderator SylenThunder's Avatar
    Join Date
    Oct 2014
    Location
    SE Michigan, out in the sticks.
    Posts
    8,344
    Rep Power
    1
    Do you have a log from when it worked?

  3. #3
    Scavenger Dox's Avatar
    Join Date
    Jan 2015
    Location
    Eastern US
    Posts
    51
    Rep Power
    0
    added, thanks

  4. #4
    Scavenger Dox's Avatar
    Join Date
    Jan 2015
    Location
    Eastern US
    Posts
    51
    Rep Power
    0
    I located this post https://stackoverflow.com/questions/...r-is-wrong-542

    export TERM=xterm
    Then verify it is changed with:

    echo $TERM
    This appears to have fixed it. /shrug.

  5. #5
    Community Moderator SylenThunder's Avatar
    Join Date
    Oct 2014
    Location
    SE Michigan, out in the sticks.
    Posts
    8,344
    Rep Power
    1
    I wonder if that's something specific to 19.04. I'll have to put up a test system and find out.

  6. #6
    Scavenger Dox's Avatar
    Join Date
    Jan 2015
    Location
    Eastern US
    Posts
    51
    Rep Power
    0
    Thats a good possibility, as very little changes took place on the system between when it was working great and then stopped. I'll have to do a little more research to understand what the command even did.

  7. #7
    Reconstructionist
    Join Date
    Dec 2015
    Posts
    677
    Rep Power
    1
    Using export to screw with the environment isn't really the best way to fix this. The TERM variable is set to "screen" in a screen session for a reason, though some terminals will over ride this. If you use xfce4-terminal, for example, it will set TERM to "xterm-256color" at startup, and in a screen session, it gets set to "screen.xterm-256color".

    Other terminals will set it to "screen", and that is where mono barfs causing the server to crash. It is mono barfing, but I'm not sure if it is a mono bug or a 7D bug. The end result is the same - the server will barf if TERM is set to "screen".

    A better fix to this, instead of using export to screw with the environment, is to modify your server startup script to set the TERM variable. In my startup script, I just add this line:

    TERM=xterm

    And it works great, and leaves the overall environment alone.

  8. #8
    Refugee
    Join Date
    Mar 2018
    Posts
    1
    Rep Power
    0
    Hello,

    Just some info :

    1) I'm not an expert in Mono, but it doesn't seem to be related to 7Days exclusively : it seems the issue arose for even simple Mono "Hello World" programs.

    2) It's also not linked specifically to Ubuntu 19.04 -> I have the same issue with my Arch/Manjaro.

    Cheers,
    MooD

  9. #9
    Reconstructionist
    Join Date
    Dec 2015
    Posts
    677
    Rep Power
    1
    Quote Originally Posted by MooD View Post
    Hello,

    Just some info :

    1) I'm not an expert in Mono, but it doesn't seem to be related to 7Days exclusively : it seems the issue arose for even simple Mono "Hello World" programs.

    2) It's also not linked specifically to Ubuntu 19.04 -> I have the same issue with my Arch/Manjaro.

    Cheers,
    MooD
    I use Slackware, and if I try to start the server in a screen session without fixing the TERM variable, it will do this every time. However, fixing the TERM variable with one line in my startup script:

    TERM=xterm

    Fixis the problem everytime.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •