It's that time of year again, the sun is hot, the days are longer, and
strange inexplicable things happen to my MUD. At any other time of the
year, I'll be the first to say it's a product of my 'hobby-standard C'
programing, but for the purposes of this test I'm running an unmodified
*stock* Circle30bpl16, on Redhat 5.2. We've had our shell account for
well over a year, and although we've had this problem before, in fact
almost a year to the day, the MUD has run pretty much without a hitch.
The solution last year was to reboot the machine we use, but
unfortunately that isn't an option this time.
I trawled through the list archives last year, and I found a short
lived thread covering a similar problem that 'Serces' (serces@mud.dk)
experienced, but I wasn't able to track down the problem with this extra
information. I posted to the list as well, but as this appears to be
such a rare occurance it didn't get a reply. I've tested a number of
different versions of CircleMUD, on different ports numbers, with
different MUD Clients, I even tried Smaug1.4a which accepted connections
without a problem. Last year the admin of our machine compiled and ran
the same *stock* version of CircleMUD we were running as a test, on the
same machine and it accepted connections without a problem. I'm was, and
still am, stumped.
What seems to happen is that when someone tries to connect to the MUD
it wakes up, goes through the
'while (!circle_shutdown)' loop once and then enters an infinite loop. I
inserted some debugging LOGs around the code below from comm.c which is
where the MUD hangs.
/* Go to sleep */
do {
circle_sleep(&timeout);
gettimeofday(&now, (struct timezone *) 0);
timediff(&timeout, &last_time, &now);
log("last_time : tv_sec = %ld, tv_usec = %ld", last_time.tv_sec,
last_time.tv_usec);
log("now : tv_sec = %ld, tv_usec = %ld", now.tv_sec,
now.tv_usec);
log("timeout : tv_sec = %ld, tv_usec = %ld", timeout.tv_sec,
timeout.tv_usec);
} while (timeout.tv_usec || timeout.tv_sec);
log("out of sleep");
Not having another shell account on another machine I don't have a
syslog of a 'normal' connection, so the log below could be nothing out
of the ordinary.
May 20 08:35:44 :: Entering game loop.
May 20 08:35:44 :: No connections. Going to sleep.
May 20 08:35:46 :: New connection. Waking up.
May 20 08:35:46 :: last_time : tv_sec = 958826146, tv_usec = 527391
May 20 08:35:46 :: now : tv_sec = 958826146, tv_usec = 533526
May 20 08:35:46 :: timeout : tv_sec = 0, tv_usec = 0
May 20 08:35:46 :: out of sleep
May 20 08:35:46 :: end of while(!circle_shutdown)
May 20 08:35:46 :: last_time : tv_sec = 958826146, tv_usec = 627391
May 20 08:35:46 :: now : tv_sec = 958826146, tv_usec = 643314
May 20 08:35:46 :: timeout : tv_sec = 21293477, tv_usec = 160000
May 20 08:35:46 :: last_time : tv_sec = 958826146, tv_usec = 627391
May 20 08:35:46 :: now : tv_sec = 958826146, tv_usec = 644787
May 20 08:35:46 :: timeout : tv_sec = 21293477, tv_usec = 160000
May 20 08:35:46 :: last_time : tv_sec = 958826146, tv_usec = 627391
*** infinite loop ***
I was under the impression that 'timeout' would be 0 if last_time <
now. I tested the same debugging code on Windows 98 and MSVC++4, and
although the gettimeofday function there is homegrown circle, timeout is
0 if last_time < now, as I would expect from the code in timediff.
I remember reading something a while back, exactly where I forget, that
suggested that 'prolonged' uptimes could cause problems with timeval and
gettimeofday on Redhat 5.2 but not being an expert I'm at a loss to
explain this odd behaviour. The machine we're on has been up for 250
days, which isn't an immense time I know, but are there any Redhat gurus
that think this could be the root of the problem?
Apologies for the length of this post, and many thanks if you've read
this far =P
-> Ben
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 04/10/01 PDT