28 Jul
2010
28 Jul
'10
5:57 p.m.
El Wed, 28 Jul 2010 22:27:26 +0200
"Olle E. Johansson" <oej(a)edvina.net> escribió:
28 jul 2010 kl. 22.18 skrev Iñaki Baz Castillo:
I do not know from the programmer point of view if this approach is feasible.
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.
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.
2010/7/28 Olle E. Johansson
<oej(a)edvina.net>et>:
Let me suggest this proposal:
- Having a dedicated kamailio process to act as syslogger.
- Other kamailio processes send logging messages to such syslogger
process by using a posix queue fifo which is non blocking. This means
that kamailio workers would never wait for the "syslog()" call to
return.
- Posix mesage queues implement a configurable queue. But also, the
syslogger process could manage its own queue (by using an array as a
FIFO system) so messages received by the posix queue would be
inserted in the FIFO and extracted from there when they are logged to
syslog.
- In this way, if syslog daemon gets frozen kamailio workers wouldn't
realize of it. Some logs would be lost in case the FIFO gets full but
this is not so important as getting Kamailio non processing SIP
messages :)
Opinnions? Do you consider it feasible?
Other people are better judges of the architecture, but I do agree with the
results. We can accept syslog messages getting lost, as long as Kamailio keeps
running the SIP handling processes.
Being a
multiprocess blocking design it would be a bit difficult such
solution. Perhaps the "ping syslog" mechanism I suggested in my
initial mail :)
I thought it wasn't easy... But still, we need some sort of solution
since this can affect a lot of systems.