Does this address openser too?
regards
klaus
-------- Original Message --------
Subject: Re: [Serdev] main_loop() initialization order
Date: Wed, 14 Feb 2007 14:14:16 +0100
From: Jan Janak <[EMAIL PROTECTED]>
To: Jan Andres <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED]
References: <[EMAIL PROTECTED]>
Jan Andres wrote:
Hi,
We have found a bug in SER and are currently a bit unsure what is the
correct approach to fix it.
The problem: main_loop() must call init_child() from the main process
before forking off the TCP listener processes. init_child() will call
the child initialization functions of all the loaded modules, and some
of them may open database sessions. The TCP listeners will inherit these
sessions after the fork(), so all TCP listeners attempt to communicate
with the database over the same TCP session, which of course fails sooner
or later, producing weird errors that are quite hard to debug.
This problem was specifically observed with the usrloc module, but it
likely affects other modules as well.
Potential solutions:
1. Fix all modules so that they don't open database sessions when their
child init functions are called in PROC_MAIN. Also, database sessions
are possibly not be the only thing affected by this issue.
2. Never run any modules' child_init_function when init_child(PROC_MAIN)
is called. As far as I can see, after it has forked all the children,
the main process does nothing but signal handling, so there should be
no need to init the modules for that process.
What are the list's opinions on this?
It appears to me that the problem is in child_init being called before
fork. I am not sure why does that happen in TCP listeners (this is
probably a question for Andrei), but child_init functions should be
called after the fork (only mod_init is called before fork). All
modules assume this behavior and hence open database connections from
child_init (to avoid inherited database connections).
Thanks for the report, we will take a look at it.
Jan.
_______________________________________________
Serdev mailing list
[EMAIL PROTECTED]
http://lists.iptel.org/mailman/listinfo/serdev
--
Klaus Darilion
nic.at
_______________________________________________
Devel mailing list
[email protected]
http://openser.org/cgi-bin/mailman/listinfo/devel
