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

Klaus Darilion klaus.mailinglists at pernau.at
Wed Feb 14 17:41:57 CET 2007


thanks
for checking ...

klaus


Bogdan-Andrei Iancu wrote:
> 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
>>
> 


-- 
Klaus Darilion
nic.at




More information about the Devel mailing list