[Devel] [Fwd: Re: [Serdev] main_loop() initialization order]

[Bogdan-Andrei Iancu]

I think it is a ser specific bug which does not exists in openser. I 
went through the openser forking process and there is nothing similar to 
what is described in the email.

regards,
bogdan

Klaus Darilion wrote:
> 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 <jan at iptel.org>
> To: Jan Andres <jan.andres at freenet-ag.de>
> CC: serdev at iptel.org
> References: <20070213085456.GA26505 at localhost.localdomain>
>
> 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
> Serdev at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serdev
>