Windows vs Linux Server Rebooter

ID:158645
 
Jul 25 2009, 11:46 am
Code:
var/ipaddress="127.0.0.1"
var/port="1709"
var/serverpath="~/byond/MyHub/dmu/dmu.dmb"
var/serveroptionals="-trusted"

world/New()
    world.log=file("Monitorlog.txt");
    Check_Server()

proc
    Check_Server()
        var/failattempts = 0
        LOOP
        var/SERVER = world.Export("[ipaddress]:[port]?ping")
        if(!SERVER)
            world.log<<"<[time2text(world.timeofday)]> Server failed to respond"
            failattempts++;
            if(failattempts>2)
                world.log<<"<[time2text(world.timeofday)]> Reboot Attempted"
                world.log<<"----------------------"
                startup(serverpath,port,serveroptionals)
                failattempts=0;
        spawn(10)
        goto LOOP


Problem description:

This code works perfectly fine on Windows.
However, neither logging output or running of a server works on a Linux machine.

Any ideas?

FYI. It's using variables because I plan to make it use an external txt file to obtain this information when I know it works solid.
Jul 25 2009, 12:58 pm
Edit: I'm wrong, didn't realize it was startup() and not shell().

In all likelyhood, serverpath needs to be an absolute path (or a relative path that doesn't use ~).

Also, once you have a proper response from the server (eg, get a ping response), you should probably set failedattempts to 0.
Jul 25 2009, 1:04 pm
In response to Slurm
Slurm wrote:
Edit: I'm wrong, didn't realize it was startup() and not shell().

In all likelyhood, serverpath needs to be an absolute path (or a relative path that doesn't use ~).

Also, once you have a proper response from the server (eg, get a ping response), you should probably set failedattempts to 0.

-Would it be wiser to use shell() and have it take considerations of linux/windows?

-I've tried relative but it doesn't explain why the log file doesn't report anything at all.

-Resetting Failed Attempts sounds wise, i'll mkae that change.
Jul 25 2009, 1:21 pm
In response to Bunnie
I don't know if it would be better, I'd imagine that using startup() would be better.

As for failedattempts, I meant something more like: (in addition to rewriting it a little to fix some issues I also saw)

var/server_host = "127.0.0.1"
var/server_port = "1709"
var/server_path = "~/byond/MyHub/dmu/dmu.dmb"
var/server_options = "-trusted"

world/New()
    world.log = file("Monitorlog.txt");
    spawn ()
        Check_Server()

proc
    Check_Server()
        var/failures = 0
        LOOP
        var/response = world.Export("[server_host]:[server_port]?ping")
        if (!isnull(response))
            failures = 0
        else
            world.log << "<[time2text(world.timeofday)]> Server failed to respond"
            failures++
            if (failures >= 3)
                world.log << "<[time2text(world.timeofday)]> Reboot Attempted"
                var/started = startup(server_path, server_port, server_options)
                world.log << "Startup: [started]"
                world.log << "----------------------"
                failures = 0;
        sleep(100)
        goto LOOP
Oct 26 2009, 9:39 am
In response to Slurm
That won't work because world.Export() holds up your Check_Server() proc until it returns something, so if the server has crashed, your proc will be stuck and it will never restart the server, because world.Export will just sit there waiting and holding up Check_Server() until the monitored server responds. So... you'll need to put spawn() in front of calling world.Export()
Oct 26 2009, 9:52 am
In response to Nielz
Hmm... Looks like I revived a dead topic. I stumbled upon this while searching the forum for "ping", trying to find out if ?ping in world.Export() returns usual milliseconds or rather ticks
Oct 26 2009, 10:57 am
In response to Nielz
It actually returns neither.

Default action:
The topic "ping" returns a true value (number of players plus one), which may be useful for telling if a server is alive. The topics "Reboot" and "Del" will call world.Reboot() and world.Del() respectively if the message was sent by the master server.

Oct 26 2009, 11:29 am
In response to Nielz
Nielz wrote:
That won't work because world.Export() holds up your Check_Server() proc until it returns something, so if the server has crashed, your proc will be stuck and it will never restart the server [...]

Um, that would've been considered very very bad behavior (or maybe even a bug, depending on how you look at it). Instead, of the server can't be contacted, then it'd return false (presumably null), and you can count on that there's also a timeout on waiting for the server to send back its response.
Oct 26 2009, 12:25 pm
In response to Kaioken
Are you sure? Because last time I tested it, which was about three days ago, world.Export() seemed to sleep endlessly when I triggered an infinite loop in a test environment.
Oct 26 2009, 12:58 pm
In response to Nielz
Well never mind what I said, I have just tested it again and this time it worked fine. Something else must have gone wrong, whatever it was.
My apologies! ^__^;
Oct 26 2009, 1:01 pm
In response to Stephen001
Okay, thanks for the info.
Oct 26 2009, 1:23 pm
In response to Kaioken
Actually, it's happening again, and I found out what causes it. So let's say environment A is doing world.Export() things to environment B. When env A calls for world.Export() while the client in env A has an alert() popup open, world.Export() jams and just sits there doing nothing and holding up the proc in which world.Export is called. Even when I close the alert() popup, world.Export is still jammed.

Any ideas?
Oct 26 2009, 9:41 pm
In response to Nielz
Nielz wrote:
Any ideas?

Yes, provide a commented code snippet of the problem, together with a detailed description in the bug tracker, after ensuring that there has been no similar report of this nature before.