Odd Linux Version Mismatch Problem

The crafting update for the new version is now available!
  • Just when I thought I could solve any of my problems by myself, reality pops up and kicks me in the butt. 8|


    Quick history:


    I have over a thousand hours in the game, been playing Steam version and recently added the standalone version for test purposes.
    I run a local server on my Mac, mostly for plugin testing, and I have a commercially-hosted linux server which I’ve been running with a number of versions of Rising World over many months now.


    The current problem:


    All is working fine on my local computer, local server and all. But now when I attempt to run it on my hosted server, I get a befuddling version mismatch error. Fact is, my hosted server think's it’s runninng version 0.8, while the startup log says it’s running 0.8.0.1.


    My client:


    The server (from the log):


    [minecraft@ValleyCraft RisingWorld]$ java -Xmx2048m -Xms1024m -jar rightDamnServer.jar
    Rising World - 0.8.0.1 - Dedicated Server
    Linux 2.6.32-042stab112.15 Java 1.8.0_05 (amd64) Memory: 1908 MB
    2017/01/04 06:51 PM


    The result:



    If I bypass the domain name and go straight for the ip address, I get a slightly different result:



    For those last attempts, I deleted the existing server.jar file, uploaded a fresh new 0.8.0.1, and even renamed it to make doubly sure that that’s the one I’m launching. My frustration *might* be apparent in the name I gave it. Apologies. :/
    I also bypassed the startup script and launched it directly from the command line, just to make extra sure.


    As you can see from the above snippet from the startup log, it appears to be running the correct version, yet, the mismatch errors persist, even after re-starting Steam from scratch. Same results running steam client or standalone version.


    Full log:


    SplinterCraft Version Conflict.txt


    I’m at my wit’s end, which is odd ‘cuz I thought my wits ended long ago. :rolleyes:

  • Sorry, the situation is probably clear to you, but I cannot figure all the pieces out. I gather that there are at least three parts:


    1) A client running on a Mac;


    2) A server running on a local machine of yours (also Mac?);


    3) A server running on a rented Linux host.


    Correct? Which pair is working and which is not working? Did you just rent the host and installed the server yourself or did you rent a pre-installed server?

    All is working fine on my local computer, local server and all. But now when I attempt to run it on my hosted server, I get a befuddling version mismatch error.


    To "run it", where "it" is what?

  • Never quite sure how to answer that question with linux. Does this help?


    cat /etc/*release
    CentOS Linux release 7.0.1406 (Core)
    NAME="CentOS Linux"
    VERSION="7 (Core)"
    ID="centos"
    ID_LIKE="rhel fedora"
    VERSION_ID="7"
    PRETTY_NAME="CentOS Linux 7 (Core)"


    This doesn't feel like a distro issue to me. The RW server seems to run fine. The client seems to run fine. The two seem to be exchanging packets just fine. I can find no stray processes running on the server.


    Is there a way to query the RW server for its version number? Somebody's lying. :D

  • Miwarre -


    I may have confused things by giving too much information. The only client I refer to is the one on my local Mac.


    The problem is between the client and the hosted server. The local server (yes, on the same Mac) works properly with the client. A copy of the exact same server jar is now running on the hosted Linux server. I do my own installs on the Linux host, and have done so for a long time.


    The client matches versions with the local server, but not the hosted server.


    Clearly I must have done something wrong, but for the life of me I can't find what.


    I am prepared for a thorough embarrassment when this is solved. <X

  • Just to be extra-sure:


    ver. 0.7.4 server.jar is long 471992 bytes
    ver. 0.8.0 server.jar is long 479733 bytes
    ver. 0.8.1 server.jar is long 480676 bytes


    (luckily I kept the previous versions, as a safety measure) This should identify the server.jar file quite univocally. (I know you know, but... do not rely on summary listings, use "ls -l" or similar for precise size info).


    If the server.jar file on the remote host matches the right size, I can only attempt some shots in the dark:


    - did you remove the 0.8.0 server?
    - did you overwrite the 0.8.0 version with the 0.8.1? Possibly some piece of the history / cache / whoknowswhat is confusing the server mind?
    - or both versions coexist side by side? (I for one would do this, to keep installation details at hand) Any chance the one actually responding to the client is the old version?
    - even more in the dark: are you extra-, super-, extra-again-sure you are directing the client to the right host?


    I understand these are things you quite surely thought of yourself too but, who knows, re-investigating these details may uncover some oddity.

  • I like the way you think, Miwarre. :thumbup:


    I will now run a "chain of custody" on the jar file in question. Never hurts to double and triple check such things, especially when the problem still exists.


    I'm pretty convinced that the jar that I launched on the hosted server is indeed a match to the one on my local computer, especially since the startup log confirms the version number. I will still double check.


    It's becoming apparent that the response being given back to the client must be coming from somewhere other than that server software. Like a phantom server process that I just haven't identified yet.


    Thanks for your clarity of thought. ;)

  • When in doubt, use a bigger hammer. :cursing:


    Spent a couple more hours tracing and re-tracing my steps and everything checked out perfectly. Rebooted everything that could be rebooted. Double-checked file sizes, properties, configs. No joy.


    SO... I finally went to the hosted server and scraped off anything and everything that had anything to do with Rising World. Right down to the metal (after making local backups, of course). Downloaded yet another fresh copy of the server zip file, and installed completely from scratch.


    And it worked.


    I will never know exactly what the problem was, but it's gone now. No doubt it was something silly, but I won't look back.


    Thanks, Miwarre. Sorry I wasted your time. Good to know you're there, though. ^^

  • I started with the zip file, expanded it, and replaced the whole enchilada.


    This was my 5th server update. I thought I had the procedure down pretty well, but I must have gotten careless bringing stuff over from the previous version to preserve the properties, scripts, world, plugins, etc.


    To put it in technical terms, I musta screwed up. :D

  • And it worked.


    I will never know exactly what the problem was, but it's gone now. No doubt it was something silly, but I won't look back.

    Glad eventually things got straight!


    Thanks, Miwarre. Sorry I wasted your time. Good to know you're there, though. ^^

    No worry! No time was "wasted"!

Participate now!

Don’t have an account yet? Create a new account now and be part of our community!