Hi Andrei,
Thanks very much for your reply.
Could you try the unstable (cvs HEAD) version? There are some SYSV lock fixes in it which were not backported to stable.
I will try it soon and report results. . (note: all builds are done with OPENBSD_IS_AOUT=no all tests are run as a non-priv user although running as root produces identical behaviors but also occassionally huge core dumps)
First I should mention the /dev/random on OpenBSD 3.2/sparc is reserved for non-existant hardware random number generators; I realize that you fall back to other methods but would it make sense to use one of the other available /dev/*random* devices in OpenBSD?
Next, an experiment was to build it with 'posix sems' support; when run as 'ser -m 8 -E -ddddddddd' I get:
0(32138) WARNING: could not read from /dev/random (5) 0(32138) read 0 from /dev/random 0(32138) seeding PRNG with 1100941542 0(32138) test random number 760286759 0(32138) ERROR: shm_mem_init: could not initialize lock 0(32138) shm_mem_destroy 0(32138) destroying the shared memory lock 0(32138) could not initialize shared memory pool, exiting... Too much shared memory demanded: 8388608 0(32138) shm_mem_destroy 0(32138) destroying the shared memory lock
note: '-m 1' in the command line produces the same behavior
/var/log/messages:
Nov 19 18:09:48 nat1 ser.posix-sems: WARNING: could not read from /dev/random (5) Nov 19 18:09:48 nat1 ser.posix-sems: ERROR: shm_mem_init: could not initialize lock Nov 19 18:09:48 nat1 ser.posix-sems: could not initialize shared memory pool, exiting...
Next, I discovered that OpenBSD 3.2 pthreads exists and fixed problems from the 2.x releases. I was able to build 'ser' with pthreads using the '-pthread' switch in the gcc command-line at link time.
Now, here are the results from running the 'pthreads' version:
$ ser -E -m 8 -ddddddddd 0(11853) WARNING: could not read from /dev/random (5) 0(11853) read 0 from /dev/random 0(11853) seeding PRNG with 1100922221 0(11853) test random number 2107379106 0(11853) shm_mem_init: success 0(11853) DEBUG: register_fifo_cmd: new command (print) registered 0(11853) DEBUG: register_fifo_cmd: new command (uptime) registered 0(11853) DEBUG: register_fifo_cmd: new command (version) registered 0(11853) DEBUG: register_fifo_cmd: new command (pwd) registered 0(11853) DEBUG: register_fifo_cmd: new command (arg) registered 0(11853) DEBUG: register_fifo_cmd: new command (which) registered 0(11853) DEBUG: register_fifo_cmd: new command (ps) registered 0(11853) DEBUG: register_fifo_cmd: new command (kill) registered Listening on 127.0.0.1 [127.0.0.1]:5060 10.0.0.100 [10.0.0.100]:5060 172.16.5.1 [172.16.5.1]:5060 216.251.177.106 [216.251.177.106]:5060 Aliases: domesys.cybertheque.org:5060 nat1.dome1-wap1:5060 nat1:5060 nat1.cybertheque.net:5060 localhost:5060 localhost.cybertheque.net:5060
Here are the major problems:
1. '-D' doesn't prevent forking to background 2. no fifo is created regardless of the 'fifo=' statement in 'ser.cfg' or the command-line '-i' argument 3. no additional debug information is logged to syslog or stderr than what is printed above (the only syslog message is "can't read from /dev/random")
Permissions are correct for creating a fifo in the specified directory (I ususally use /tmp).
'ser -c' reports 'ser.cfg' is ok.
The build of the 'ser' executable had no warnings; the only changes I made were to Makefile.defs for the build environment and to 'locking.h':
66,69d65 < /* Addn'l defines -- MSG */ < #ifndef L_CRIT < #define L_CRIT 2 < #endif 74d69 < #include <sys/errno.h>
These were necessary to complete the build.
I would appreciate any advice before I start peppering the code with printfs.
Regards,
Michael Grigoni Cybertheque Museum
On Nov 19, 2004 at 21:14, msg michael.grigoni@cybertheque.org wrote:
Hi Andrei,
Thanks very much for your reply.
Could you try the unstable (cvs HEAD) version? There are some SYSV lock fixes in it which were not backported to stable.
I will try it soon and report results. . (note: all builds are done with OPENBSD_IS_AOUT=no all tests are run as a non-priv user although running as root produces identical behaviors but also occassionally huge core dumps)
First I should mention the /dev/random on OpenBSD 3.2/sparc is reserved for non-existant hardware random number generators; I realize that you fall back to other methods but would it make sense to use one of the other available /dev/*random* devices in OpenBSD?
Yes, I know. It's fixed on HEAD (/dev/urandom instead of /dev/random).
Next, an experiment was to build it with 'posix sems' support; when run as 'ser -m 8 -E -ddddddddd' I get:
0(32138) WARNING: could not read from /dev/random (5) 0(32138) read 0 from /dev/random 0(32138) seeding PRNG with 1100941542 0(32138) test random number 760286759 0(32138) ERROR: shm_mem_init: could not initialize lock 0(32138) shm_mem_destroy 0(32138) destroying the shared memory lock 0(32138) could not initialize shared memory pool, exiting... Too much shared memory demanded: 8388608 0(32138) shm_mem_destroy 0(32138) destroying the shared memory lock
note: '-m 1' in the command line produces the same behavior
/var/log/messages:
Nov 19 18:09:48 nat1 ser.posix-sems: WARNING: could not read from /dev/random (5) Nov 19 18:09:48 nat1 ser.posix-sems: ERROR: shm_mem_init: could not initialize lock Nov 19 18:09:48 nat1 ser.posix-sems: could not initialize shared memory pool, exiting...
Next, I discovered that OpenBSD 3.2 pthreads exists and fixed problems from the 2.x releases. I was able to build 'ser' with pthreads using the '-pthread' switch in the gcc command-line at link time.
Now, here are the results from running the 'pthreads' version:
$ ser -E -m 8 -ddddddddd 0(11853) WARNING: could not read from /dev/random (5) 0(11853) read 0 from /dev/random 0(11853) seeding PRNG with 1100922221 0(11853) test random number 2107379106 0(11853) shm_mem_init: success 0(11853) DEBUG: register_fifo_cmd: new command (print) registered 0(11853) DEBUG: register_fifo_cmd: new command (uptime) registered 0(11853) DEBUG: register_fifo_cmd: new command (version) registered 0(11853) DEBUG: register_fifo_cmd: new command (pwd) registered 0(11853) DEBUG: register_fifo_cmd: new command (arg) registered 0(11853) DEBUG: register_fifo_cmd: new command (which) registered 0(11853) DEBUG: register_fifo_cmd: new command (ps) registered 0(11853) DEBUG: register_fifo_cmd: new command (kill) registered Listening on 127.0.0.1 [127.0.0.1]:5060 10.0.0.100 [10.0.0.100]:5060 172.16.5.1 [172.16.5.1]:5060 216.251.177.106 [216.251.177.106]:5060 Aliases: domesys.cybertheque.org:5060 nat1.dome1-wap1:5060 nat1:5060 nat1.cybertheque.net:5060 localhost:5060 localhost.cybertheque.net:5060
Here are the major problems:
- '-D' doesn't prevent forking to background
- no fifo is created regardless of the 'fifo=' statement in 'ser.cfg' or the command-line '-i' argument
- no additional debug information is logged to syslog or stderr than what is printed above (the only syslog message is "can't read from /dev/random")
Did you comment out log_stderror and fork in ser.cfg? ser.cfg takes precedence over the command line (so if you have fork=yes in ser.cfg, -D will be ignored).
Permissions are correct for creating a fifo in the specified directory (I ususally use /tmp).
Strange, I've tried this on openbsd 3.2/x86 and it works.
Andrei
I experimented over the weekend but was too tired to post the results :-)
Here are the major problems:
- '-D' doesn't prevent forking to background
The single process which runs in the background does indeed work as confirmed with tests using 'sipsak', but only on one interface (loopback, unless it is explicitly specified in ser.cfg).
Without using command-line options: "fork=yes" set in ser.cfg results on only a single process running in the background "fork=no" set in ser'cfg results in several processes starting followed by a segfault (in one of them, the rest remain running): (gdb) bt #0 0x83a2584 in _atomic_lock () #1 0x83a2564 in _spinlock_debug ()
also, the fifo is created and 'serctl ps' will list the (2) running processes, but this query will kill those processes.
I tried running with various values of shmem (-m 4, 8, 12, etc) which doesn't seem to change the behavior but changes the corefile size somewhat. The machine has 16MB RAM and 500MB swap space -- for the mixture of tasks it runs as a router (isakmpd, pf, snort, various proxies) it never swaps; the swap space is there for big compiles -- I vainly tried building OpenH323 and after eight days it gave up on h323.cxx -- note that searching archives shows others have been unable to build it on OpenBSD/sparc regardless of how much ram they have.
For my intended application (a few phones on our natted lan) I wouldn't mind using just a single process with a very small memory footprint, but it would need to listen on all of the interfaces and work with rtpproxy.
- no fifo is created regardless of the 'fifo=' statement in 'ser.cfg'
or the command-line '-i' argument
Did you comment out log_stderror and fork in ser.cfg? ser.cfg takes precedence over the command line (so if you have fork=yes in ser.cfg, -D will be ignored).
See above for strange behavior.
Permissions are correct for creating a fifo in the specified directory (I ususally use /tmp).
See above -- fifo is created if "fork=no"
Strange, I've tried this on openbsd 3.2/x86 and it works.
Andrei
Regards,
Michael Grigoni Cybertheque Museum
I increased the installed ram in this box to 40MB (all I had -- it maxes out at 64MB anyway) with no change in the behavior; I tried running with '-m 2, -m 4 -m 6 -m 8 and default (-m 32)' -- with '-m 2' two processes start and there is no core dump but 'serctl ps' will kill one of them and the other one hangs (in a loop accessing something in the filesystem -- haven't traced it yet). This is with 'fork=no' in ser.cfg. Only with 'fork=yes' will ser start (only one process) and run stable. Regardless of the fork setting, ser will not remain in the foreground.
Without using command-line options: "fork=yes" set in ser.cfg results in only a single process running in the background; "fork=no" set in ser'cfg results in several processes starting followed by a segfault (in one of them, the rest remain running): (gdb) bt #0 0x83a2584 in _atomic_lock () #1 0x83a2564 in _spinlock_debug ()
also, the fifo is created and 'serctl ps' will list the (2) running processes, but this query will kill those processes.
Michael
FWIW I put the makelog for the pthreads version (along with some generated config files) in: ftp://ftp.cybertheque.org/pub/ser/
I'd gladly provide an account on this box to get ser running.
Regards,
Michael
-
Andrei Pelinescu-Onciul -
msg