I've been playing with ser for a while checking it in different scenarios. All this time I used it with fork=no log_stderror=yes settings and it worked. Now I've come up with some draft ser.cfg and wanted to run it as daemon. I've changed it to fork=yes log_stderror=no and now ser doesn't start. Actually "log_stderror=no" is the setting that causes problem. If it's set to "yes", ser starts fine even in forked mode. Also I narrowed down the problem to postgres module. If I remove it from ser.cfg then ser starts as it should. With postgres module enabled it doesn't throw a word of complaint to a log and it looks fine from console:
root@pg1old:~/src/ser/ser-0.9.3# /usr/local/ser/sbin/ser -f /etc/ser/ser.cfg Listening on udp: 192.168.0.61 [192.168.0.61]:5060 tcp: 192.168.0.61 [192.168.0.61]:5060 Aliases: tcp: pg1old:5060 tcp: pg1old.acecape.com:5060 udp: pg1old:5060 udp: pg1old.acecape.com:5060 *: 192.168.0.61:*
but root@pg1old:~/src/ser/ser-0.9.3# ps -auxw | grep ser root 18322 0.0 0.3 38836 1824 ? S 15:05 0:00 /usr/local/ser/sbin/ser -f /etc/ser/ser.cfg
shows that there's just one ser process running, netstat shows that it's not listening on any port and also no FIFO file is created. Again everything works fine if "log_stderror" set to "yes". Looks to me as some strange bug. Any clues? Thanks,
Michael Ulitskiy
On Mon, 18 Jul 2005, Michael Ulitskiy wrote:
and now ser doesn't start. Actually "log_stderror=no" is the setting that causes problem. If it's set to "yes", ser starts fine even in forked mode. Also I narrowed down the problem to postgres module. If I remove it from ser.cfg then ser starts as it should.
See, http://lists.iptel.org/pipermail/serdev/2005-July/005148.html
I guess postgres could be multi-threaded.
Guys, isn't it time to make (as described in the referenced message) SER more friendly to multi-threaded third-party libraries?
Yeap, it worked for me too. Thanks a lot. Are there any expected side-effects?
Michael
On Tuesday 19 July 2005 04:44 am, Dmitry Semyonov wrote:
On Mon, 18 Jul 2005, Michael Ulitskiy wrote:
and now ser doesn't start. Actually "log_stderror=no" is the setting that causes problem. If it's set to "yes", ser starts fine even in forked mode. Also I narrowed down the problem to postgres module. If I remove it from ser.cfg then ser starts as it should.
See, http://lists.iptel.org/pipermail/serdev/2005-July/005148.html
I guess postgres could be multi-threaded.
Guys, isn't it time to make (as described in the referenced message) SER more friendly to multi-threaded third-party libraries?
-- ...Bye..Dmitry.
On Jul 19, 2005 at 12:44, Dmitry Semyonov dsemyonov@dins.ru wrote:
On Mon, 18 Jul 2005, Michael Ulitskiy wrote:
and now ser doesn't start. Actually "log_stderror=no" is the setting that causes problem. If it's set to "yes", ser starts fine even in forked mode. Also I narrowed down the problem to postgres module. If I remove it from ser.cfg then ser starts as it should.
See, http://lists.iptel.org/pipermail/serdev/2005-July/005148.html
I guess postgres could be multi-threaded.
Guys, isn't it time to make (as described in the referenced message) SER more friendly to multi-threaded third-party libraries?
-D_REENTRANT might adversely affect performance (thread safe means locking which is slow). So far only postgres, cpl-c and pa link (indirectly) to libpthread. The problem seem to appear only for logging to syslog and only on some specific linux distributions (I was not able to reproduce it on debian64 for example). The proper fix would be to use -DREENTRANT only for the code that really needs it (e.g only the postgres module or only the dprint.h/syslog part). Unfortunately since I cannot reproduce the problem, I cannot test a potential fix.
Andrei
-
Andrei Pelinescu-Onciul -
Dmitry Semyonov -
Michael Ulitskiy