2010/7/28 Jon Bonilla manwe@aholab.ehu.es:
I do not know from the programmer point of view if this approach is feasible.
I've coded a very similar solution for a personal project and works really well under scenarios with high traffic so I consider it feasible, I just wonder if it's feasible from the current Kamailio design point of view.
But kamailio is never the only process running in a system. Other processes as cron, a mta, ssh server (at least) run in the same machine. If syslog is blocked, you might get a frozen system anyways. Almost every service relies on syslog, which makes this solution incomplete.
Sure, but anyway I don't care ssh, a mta (never running in my kamailio servers!) or cron (just to rotate logs, no more). If kamailio remains working that's what I need :)
I think that the solution to this problem is in syslog's side. It's a critical service in any system and this solution would just mask the problem.
Don't think in my suggestion just from the point of view of "reliability" but also think in "efficience":
Currently a kamailio worker must wait for the syslog() call to return before continuing processing the SIP message (blocking design). Using a posix queue the worker sends the log to it which is not a blocking call. Just the kamailio syslogger process should have to deal with syslog daemon.
Regards.