Daniel-Constantin Mierla writes: i needed to switch to earlier working version, but can try to reinstall later this non-working version later today. i'm using xmlrpc module. size of my syslog is > 12 MB due to these error messages. first error message is this: Sep 30 12:21:42 sip /usr/sbin/sip-proxy[27211]: ERROR: <core> [db_id.c:247]: error while parsing database URL: 'mysql://user:pass@localhost/ser' perhaps it has something to do with later mi related error messages? has someone changed something is parsing of db URLs? if so, please revert and i'll try again. -- juha

daniel, can't you make a change somewhere that stops execution of sr, when this error occurs? now it keeps on running endlessly and produces huge syslog. it would then be earier to debug the problem? -- juha Sep 30 12:21:42 sip /usr/sbin/sip-proxy[27211]: ERROR: <core> [db_id.c:247]: error while parsing database URL: 'mysql://user:pass@localhost/ser' Sep 30 12:21:42 sip /usr/sbin/sip-proxy[27211]: ERROR: <core> [db.c:291]: cannot parse URL 'mysql://user:pass@localhost/ser' Sep 30 12:21:42 sip /usr/sbin/sip-proxy[27211]: ERROR: permissions [address.c:293]: unable to connect database Sep 30 12:21:42 sip /usr/sbin/sip-proxy[27211]: ERROR: <core> [mi.c:112]: failed to init <address_reload> Sep 30 12:21:42 sip /usr/sbin/sip-proxy[27211]: CRITICAL: mi_rpc [mi_rpc_mod.c:84]: Failed to init the mi commands Sep 30 12:21:42 sip /usr/sbin/sip-proxy[27211]: ERROR: <core> [sr_module.c:882]: init_mod_child(): Error while initializing module mi_rpc (/usr/lib/sip-proxy/modules/mi_rpc.so) Sep 30 12:21:42 sip /usr/sbin/sip-proxy[27211]: CRITICAL: mi_rpc [mi_rpc_mod.c:84]: Failed to init the mi commands Sep 30 12:21:42 sip /usr/sbin/sip-proxy[27211]: ERROR: <core> [sr_module.c:882]: init_mod_child(): Error while initializing module mi_rpc (/usr/lib/sip-proxy/modules/mi_rpc.so) ...... forever

ok, the mi child init loop should be fixed with latest commit. Let me know if it is. Do you still get the error with db url parsing? Cheers, Daniel On 9/30/11 1:24 PM, Daniel-Constantin Mierla wrote: -- Daniel-Constantin Mierla -- http://www.asipto.com Kamailio Advanced Training, Dec 5-8, Berlin: http://asipto.com/u/kat http://linkedin.com/in/miconda -- http://twitter.com/miconda

Did a fix for the warnings and refactored the previous one. Try again and let me know the results. Thanks, Daniel On 9/30/11 1:40 PM, Juha Heinanen wrote: -- Daniel-Constantin Mierla -- http://www.asipto.com Kamailio Advanced Training, Dec 5-8, Berlin: http://asipto.com/u/kat http://linkedin.com/in/miconda -- http://twitter.com/miconda

On 9/30/11 2:26 PM, Juha Heinanen wrote: the changes were not big by themselves, it was about when to call child_init and mi_child_init functions. By design, and some time ago all was ok, there were created different processes handling SIP and handling MI (RPC), each calling an init function (if needed) after the process was forked, namely child_init from module exports structure by SIP workers and mi_child_init from MI commands export structure by MI workers. But with the time, it got to the state when MI/RPC workers call route blocks (where are functions exported by modules to handle sip) and SIP workers have to handle RPC commands. Therfore in some cases, a process is both SIP and RPC/MI worker. The changes tried to detect when is such a case and initialize properly the children processes. So, initially was added local_route introduced during openser/kamailio stand alone times, right now it is event_route[tm:local-request]. This route block is executed for local generated requests via tm. But such requests can be triggered by MI commands, thus handled by a MI worker (e.g., end dlg from dialog, pua_mi, t_uac* MI commands). An event route can have all functions available for REQUEST_ROUTE, but some of them do not work if module child_init was not called for that process. A good example is acc_db_request() -- it requires child_init to connect to database, on the other hand, acc has no mi command in order to have a mi_child_init function. If one sends a dlg end MI command and then want to account the generated BYEs to acc table, it failed in the past. To work properly, each MI/RPC worker has to execute the child_init functions exported by modules The other case is when SIP workers have to execute MI/RPC commands. It is the case when xmlrpc module is used, because this module works on the same transport layer as for SIP, the XMLRPC requests being handled by the same workers as SIP requests. For this, each SIP worker has to execute the mi_child_init exported by MI commands. This was partially fixed, by having mi_rpc module search to see if xmlrpc module was loaded and call mi_child_init functions in child_init. The changes were: - core keeps some flags about the type of the process, if it is going to handle SIP functions and/or RPC commands - when tm is initialized, if event_route[tm:local-request] is defined, tells to core that RPC workers may execute SIP functions - when xmlrpc is loaded, tells to the core that SIP workers may handle RPC commands - based on this flags, mi_rpc module calls the mi_child_init() function in child_init() and the MI core API calls child_init() functions when initalizing MI workers I haven't gotten to ctl module to see if it needs to do any fix for its extra workers, in the case event_route is going to be used from them. Cheers, Daniel -- Daniel-Constantin Mierla -- http://www.asipto.com Kamailio Advanced Training, Dec 5-8, Berlin: http://asipto.com/u/kat http://linkedin.com/in/miconda -- http://twitter.com/miconda