19 Apr
2010
19 Apr
'10
8:51 p.m.
2010/4/19 Henning Westerholt <henning.westerholt(a)1und1.de>de>:
i think its a bit of a problem that the init script
can block somehow, as this
causes delays for the system start. But on the other hand, kamailio is not
really desktop software..
Sure, it's a server software and that's the reason that return codes
must be precise.
But if we could allow the init script to block for
some time, what about this
(IMHO much simpler) approach:
* kamailio gets started as usual
* init script sleeps for some time (e.g. 5-10 seconds, configurable)
* init script checks if the process is really running (process list, FIFO,
SIP OPTIONS..)
* init script returns the appropriate return code
Not sure if you already considered this.
I've done the same for some other services wrongly managing exit
status codes. Sincerely I consider it a bad workaround, not reliable
and ugly (why to force a timeout if the init script could exit
quickly?). Also note that usually HeartBeat waits just a limited
ammount of seconds when it starts a service.
Perhaps we could forget the corner case of the timeout as it would
only occur if the main process blocks without exiting and without
previously writing into the pipe (if it occurs then we have bigger
problems, something that must be fixed in the code and not something
related to a DB connection error or wrong socket).
I really think that the pipe mechanism is the best approach here as it
allows getting the real status of the main process, and quickly.
Regards.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>