mudos time() and heart_beat() issues with new linux install

[yeik]

The server that the mud i help with was recently upgraded to a newer version of ubuntu.
After coming back up, we had to change the libraries from 32 bit to 64 bit, and we were able to get the mud up and running
but time() doesn't update, and heart_beat() doesn't appear to be working.
I wondered if anybody had some insight on this problem.
Thanks
Yeik

[cratylus]

You might want to see if this is related:

http://lpmuds.net/forum/index.php?topic=402.msg1739#msg1739

-Crat

[Tricky]

It seems that the call_out's and heart_beat's aren't being called and as such current_time in the driver isn't being updated.

Maybe whatever the Discworld maintainers did solved this problem for FluffOS 2.

Tricky

PS - FluffOS 2 works for LPUni just not on a windows box yet.

[chaos]

I've seen problems like that in situations where a heart_beat() or call_out() is persistently erroring and not being turned off, and everything that runs based on time winds up getting all screwed up.  Dunno if it's relevant, but you might need to check your error logs (lpmud.log and host.debug.log for me, maybe different for you) and see if something's spewing errors.

[quixadhal]

Not having looked at the MudOS source for quite a few years, my ignorant suggeston for a fix would be to make sure that current_time is updated at the bottom of the driver loop that checks for socket activity, rather than relying on call_outs or heart_beat's (which may be disabled).

As per the other thread, if that isn't the problem, then most likely your version of usleep() doesn't fudge values, and somewhere, the driver expects it to do so.

[Tricky]

This is why I suggested FluffOS 2, the maintainers seem to have solved the problem for 64 bit machines.

Tricky

[cratylus]

Someone provided me access to a 64 bit Linux box:

Linux <hostname> 2.6.18-5-amd64 #1 SMP Thu May 31 23:51:05 UTC 2007 x86_64 GNU/Linux

As you can see it is a 64 bit SMP kernel.

I used ds2.5a12. There is a bug that prevents logins on this platform.
you can fix it by editing /secure/sefun/sefun.c and in users() replacing:

Code:

object *ret = filter(efun::users(), (: ($1) && environment($1) :) );

with:

Code:

    object *ret = ({});
    if(sizeof(efun::users()))
        foreach(mixed foo in efun::users()){
           if(foo && environment(foo)) ret += ({ foo });
    }

Once this login bug was fixed, I was able to log in and use heart_beat()
and time() with no problems whatsoever.

I repeated this process with ds2.4.2 and it also worked fine.

Since you are using lpuni, this is of limited relief to you, but
you might want to try using the driver source from DS with the
local_options from lpuni and seeing if this resolves your problem.

-Crat

[Tricky]

Hmm...

Login isn't a problem, unless I am completely mis-understanding your definition of login bug. Secondly, users() isn't over-ridden in LPUni. Maybe it should be.

I'm tending to lean towards the ualarm theory atm.

Tricky

[cratylus]

Login isn't a problem, unless I am completely mis-understanding your definition of login bug. Secondly, users() isn't over-ridden in LPUni. Maybe it should be.

The login bug information was just to provide context. It seems irrelevant
because it's aimed to help DS folks *also*, who run into the login problem.

But the point is that this time() and heart_beat() thing doesn't happen
on DS, so he might want to try using the DS MudOS source with the lpuni
local_options, since that should be easier to do than trying to port
his lpuni mud to FluffOS.

-Crat

[Tricky]

No porting required. Just local_options needs updating with the new stuff that was introduced with FluffOS.

Tricky

[cratylus]

Oh, cool. Din't know that.

Sounds like Yeik should be able to take his pick
of solutions then.

-Crat

[yeik]

changing the driver to fluffos worked, but now am having issues with things throughout the mud, such as who
keeps saying im trying to put a string into an object

"Error: *Trying to put string in object"

interestingly enough i can't find where it is trying to do this or why as it says the line it is looking at is actually outside of the file it indicates.

[yeik]

I did try the MudOS driver from the DS package but it had the same issues with the time() and heart_beat() i tried changing a few things, tried adding       -m32 to the CFLAG but it would always give me a compile error.

FluffOS was pretty easy to port to, there are a few more things i want to try to see what happens.

[yeik]

YAY! got who fixed, and the errors sort of figured out
it seems
FluffOS is more strict about the type of arrays and MudOS is very loose
one of the other coders apparently had object array instead of string array
that caused all these issues

[wodan]

iirc, ualarm adds the secs to the usecs and then uses those for the usecs field in setitimer, which recently (last libc update i had) has stopped accepting such abuse (this would be in libc). So basically, don't use ualarm for > 1 second timer intervals now. I doubt they'll fix it as ualarm is marked obsolete in its manpage.

FluffOS 2.8 is no longer using ualarm and should be out soonish, 2.6 and 2.7 should run but probably won't detect too long evaluation errors.

MudOS uses it for the heart_beat interval timing and probably needs a patch to work on systems with this "feature"