26 Feb, 2010, arholly wrote in the 1st comment:
Votes: 0
Hello:
I'm having problems starting up my mud (stock ROM24b) in the latest version of ubuntu. I get it to compile (after fixing the tables.h issue), but when I go to do
startup &
or
startup 9000 &
and when I do that, it closes the terminal. Any thoughts?
26 Feb, 2010, bbailey wrote in the 2nd comment:
Votes: 0
arholly said:
Hello:
I'm having problems starting up my mud (stock ROM24b) in the latest version of ubuntu. I get it to compile (after fixing the tables.h issue), but when I go to do
startup &
or
startup 9000 &
and when I do that, it closes the terminal. Any thoughts?


What specific version of Rom are you using? What terminal program are you using, and are you accessing the host locally or remotely? Could you elaborate more on 'closes the terminal'? Are you getting any error messages or other unexpected output? Does it literally terminate the connection/close the terminal window?

The main issues I experience on Ubuntu 9.10 is having the proper development packages installed to compile the mud, and also having a compatible C shell installed if I plan to use Rom's default startup script. You say you've already compiled it so I'll assume that development packages are correctly installed. If you're getting error messages like the below, then you'll need to install a C shell (I prefer tcsh). E.g., "apt-get install tcsh".
Quote
bash: ./startup: /bin/csh: bad interpreter: No such file or directory


Beyond that, I'm not sure what trouble you may be having. Rom works well on my Ubuntu 9.10 system:

Quote
bobby@omega:~$
bobby@omega:~$ cd Rom24/src
bobby@omega:~/Rom24/src$ make
make: `rom' is up to date.
bobby@omega:~/Rom24/src$ cd ../area
bobby@omega:~/Rom24/area$ nohup ./startup 9000 &
[1] 2609
bobby@omega:~/Rom24/area$ nohup: ignoring input and appending output to `nohup.out'

bobby@omega:~/Rom24/area$ ps aux | grep rom
bobby 2610 1.0 0.2 5452 3776 pts/0 S 14:49 0:00 ../src/rom 9000
bobby 2616 0.0 0.0 3040 800 pts/0 S+ 14:50 0:00 grep –color=auto rom
bobby@omega:~/Rom24/area$
26 Feb, 2010, jurdendurden wrote in the 3rd comment:
Votes: 0
Should be using: nohup ./startup &
26 Feb, 2010, arholly wrote in the 4th comment:
Votes: 0
OK, that worked. Thanks. It must because I didn't have the C shell installed. Thanks for that.

What's the nohup command?
26 Feb, 2010, jurdendurden wrote in the 5th comment:
Votes: 0
It tells it to ignore the hangup signal, so the mud doesn't stop when you log out of the shell.
26 Feb, 2010, David Haley wrote in the 6th comment:
Votes: 0
'nohup' means "no hang up", or, "don't kill the following program when I hang up my terminal".
26 Feb, 2010, Tyche wrote in the 7th comment:
Votes: 0
The nohup command sets a signal handling for SIGHUP to ignore and then executes your mud.
SIGHUP is often issued to all the child processes owned by your user id when you logoff a system.
You can update your rom mud code to ignore SIGHUP as well…
signal (SIGHUP, SIG_IGN);


That way you won't need to use nohup to start it up and logoff
26 Feb, 2010, arholly wrote in the 8th comment:
Votes: 0
Any thoughts on why I'm getting this?
gcc -c -Wall -O -g  comm.c
comm.c: In function init_descriptor:
comm.c:868: warning: pointer targets in passing argument 3 of getsockname differ in signedness
/usr/include/sys/socket.h:119: note: expected socklen_t * __restrict__ but argument is of type int *
comm.c:869: warning: pointer targets in passing argument 3 of accept differ in signedness
/usr/include/sys/socket.h:214: note: expected socklen_t * __restrict__ but argument is of type int *
comm.c:898: warning: pointer targets in passing argument 3 of getpeername differ in signedness
/usr/include/sys/socket.h:133: note: expected socklen_t * __restrict__ but argument is of type int *


Again, it's stock. I know it's just a warning, but I prefer working from a clean compile and want to understand what it's saying, not just have it fixed as well.

Thanks,
Arholly
26 Feb, 2010, jurdendurden wrote in the 9th comment:
Votes: 0
Hmm which version of Rom are you running? Have you thought about using quickmud as it's bugs are pretty much ironed out?
26 Feb, 2010, Tyche wrote in the 10th comment:
Votes: 0
arholly said:
Any thoughts on why I'm getting this?
gcc -c -Wall -O -g  comm.c
comm.c: In function init_descriptor:
comm.c:868: warning: pointer targets in passing argument 3 of getsockname differ in signedness
/usr/include/sys/socket.h:119: note: expected socklen_t * __restrict__ but argument is of type int *
comm.c:869: warning: pointer targets in passing argument 3 of accept differ in signedness
/usr/include/sys/socket.h:214: note: expected socklen_t * __restrict__ but argument is of type int *
comm.c:898: warning: pointer targets in passing argument 3 of getpeername differ in signedness
/usr/include/sys/socket.h:133: note: expected socklen_t * __restrict__ but argument is of type int *


Again, it's stock. I know it's just a warning, but I prefer working from a clean compile and want to understand what it's saying, not just have it fixed as well.

Thanks,
Arholly


Use variables defined as socklen_t* instead of int* in the third argument in function calls to getsockname, accept and getpeername.

Hmm… all I did was translate the messages to semi-english.
27 Feb, 2010, arholly wrote in the 11th comment:
Votes: 0
So, should it look like this:
socklen_t	getsockname	args( ( int s, struct sockaddr *name, int *namelen ) );
27 Feb, 2010, Tyche wrote in the 12th comment:
Votes: 0
arholly said:
So, should it look like this:
socklen_t	getsockname	args( ( int s, struct sockaddr *name, int *namelen ) );


No. That's not a function call, that's a function declaration. There shouldn't be any declarations of ansi or posix functions in the rom code at all. I am aware the stock code has some though. You should remove them and rely on what's in the headers. The warning messages you posted indicate that the correct declarations are already being seen, rather those functions are not being called correctly at the lines indicated in the warning messages.

It's far easier to give more explicit information when you post the actual lines in question indicated by the warning messages and some context around them.
27 Feb, 2010, arholly wrote in the 13th comment:
Votes: 0
getsockname( control, (struct sockaddr *) &sock, &size );
if ( ( desc = accept( control, (struct sockaddr *) &sock, &size) ) < 0 )
{
perror( "New_descriptor: accept" );
return;
}

The first two lines are 868 and 869. The first line here is line 898.
if ( getpeername( desc, (struct sockaddr *) &sock, &size ) < 0 )
{
perror( "New_descriptor: getpeername" );
dnew->host = str_dup( "(unknown)" );
}


For a refresher, the warnings were.
gcc -c -Wall -O -g  comm.c
comm.c: In function init_descriptor:
comm.c:868: warning: pointer targets in passing argument 3 of getsockname differ in signedness
/usr/include/sys/socket.h:119: note: expected socklen_t * __restrict__ but argument is of type int *
comm.c:869: warning: pointer targets in passing argument 3 of accept differ in signedness
/usr/include/sys/socket.h:214: note: expected socklen_t * __restrict__ but argument is of type int *
comm.c:898: warning: pointer targets in passing argument 3 of getpeername differ in signedness
/usr/include/sys/socket.h:133: note: expected socklen_t * __restrict__ but argument is of type int *
27 Feb, 2010, Tyche wrote in the 14th comment:
Votes: 0
In all three calls…

getsockname( control, (struct sockaddr *) &sock, &size );
if ( ( desc = accept( control, (struct sockaddr *) &sock, &size) ) < 0 )
{
perror( "New_descriptor: accept" );
return;
}
if ( getpeername( desc, (struct sockaddr *) &sock, &size ) < 0 )
{
perror( "New_descriptor: getpeername" );
dnew->host = str_dup( "(unknown)" );
}

the bolded variable size which is used as the third argument to the calls is probably declared somewhere in your code as something similar to…

int* size;

when it should be…

socklen_t* size;
27 Feb, 2010, arholly wrote in the 15th comment:
Votes: 0
OK, so I changed a part of the code to:
void init_descriptor( int control )
{
char buf[MAX_STRING_LENGTH];
DESCRIPTOR_DATA *dnew;
struct sockaddr_in sock;
struct hostent *from;
int desc;
socklen_t * size;

size = sizeof(sock);
getsockname( control, (struct sockaddr *) &sock, &size );
if ( ( desc = accept( control, (struct sockaddr *) &sock, &size) ) < 0 )
{
perror( "New_descriptor: accept" );
return;
}


When I do that, it gave me a different error. Now, this also set off some other areas where I was getting about changing it from int to socklen_t, so why is it now saying
comm.c: In function init_descriptor:
comm.c:896: warning: assignment makes pointer from integer without a cast
comm.c:897: warning: passing argument 3 of getsockname from incompatible pointer type
27 Feb, 2010, Kline wrote in the 16th comment:
Votes: 0
Use socklen_t size;
27 Feb, 2010, arholly wrote in the 17th comment:
Votes: 0
You are one of my new heroes. :grinning:

That worked. Thanks for the help.

Now, what is the difference between socklen_t and int? I just want to be clear when I'm doing work down the road. Thanks.

Arholly
27 Feb, 2010, Kline wrote in the 18th comment:
Votes: 0
Portability.

Quote
This new type is defined to be the same as int on most platforms.
27 Feb, 2010, arholly wrote in the 19th comment:
Votes: 0
OK, so that only get's used for socket type stuff, not other stuff. At least, I'm pretty sure that's what the link says, correct?
27 Feb, 2010, Kline wrote in the 20th comment:
Votes: 0
As I understand things yes. socklen_t should just guarantee a minimum length for a number since on one system an 'int' by default may be signed but on another may be unsigned. Just removes some ambiguity from things; same with size_t.
0.0/26