Recent server outages.

Please Note: The TotalFreedom Forum has now been put into a read-only mode. Total Freedom has now closed down and will not be returning in any way, shape or form. It has been a pleasure to lead this community and I wish you all the best for your futures.

    So in the past day or so I've noticed the server has gone down and been unable to be restarted through the admin console commands (tf!start, tf!stop and tf!kill all return with "something went wrong" errors).

    I've just made this thread to try and spark some discussion and/or investigation. Is there anything that may be causing this? - is it an issue with the fact the server is crashing at all or the manner in which it crashes that renders the bot commands useless?

    This is becoming a concerning trend and the only people able to sort it out have direct console access - so I think it needs looked at.

    Patrolling the Mojave almost makes you wish for a nuclear winter.

    Need to dig into why the bot isn't doing what it should be. I've restarted everything on the vps to see if it'll play better and have raised a bug to catch one of the errors that resulted in a crash earlier.

    Wild1145

    Network Owner at TotalFreedom

    Managing Director at ATLAS Media Group Ltd.

    Founder & Owner at MastodonApp.UK

    So I found a solution and it’s what we’ve done commonly. If it lags, run tf!stop from the BOT ASAP and restart it with tf!start.

    I’m disabling redstone for the night and halting activity (the halt-activity cmd). If a more experienced admin/senior wants to re-enable it please do but I only am doing this for the stability of the server.

    Update:

    The server won’t stop dying after 3 minutes or so of it being online. Me and Ria tried to find the cause but we can’t. I’m leaving the server in adminmode only for the night and I am sorry it has come to this.

    Quote

    ↩  You! So I found a solution and it’s what we’ve done commonly. If it lags, run tf!stop from the BOT ASAP and restart it with tf!start.

    This is what we are doing. The server isn't responding to either of those two commands and we need someone with server access to come and start it from console.

    And if you meant to add the ASAP thing, it's very hard to tell when the server is down until it's far too late. Especially as chat continues to work fine enough. We're human beings, we can't always catch it right away - look at how we missed someone using minecarts at spawn - what sounds on paper to be an easy issue to sort out, yet almost left the server unaccessible by non-admins overnight. (I am not taking a jab or blaming you as I probably wouldn't have acted much differently myself)

    Patrolling the Mojave almost makes you wish for a nuclear winter.

    Quote

    ↩  erin And if you meant to add the ASAP thing, it's very hard to tell when the server is down until it's far too late. Especially as chat continues to work fine enough.

    Because of this thread, I’ve been stopping it as soon as commands don’t go through. Do that for now maybe? Idk

    Quote

    ↩  You! If it lags, run tf!stop from the BOT ASAP

    Better not. If the server manages to shut down properly, you'll save the world with the lag source, and that's what's happened to the recent minecarts incident.

    I also prefer using /stoplag (aka halt-activity) only after /ew and /bre failed. It'll grief buildings and bypass petprotect. WorldGuard's documentation says "this command should be reserved for extremely desperate occasions".

    I've seen that, If the server's TPS rapidly drops to a single digit and we don't know what's causing it, /ew -a (from telnet if possible) usually saves the day.

    TotalFreedom's Executive Community & Marketing Manager