On Nov 19, 2004 at 21:14, msg <michael.grigoni(a)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:
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")
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