31 Jan
2005
31 Jan
'05
7:24 p.m.
Hi,
thanks for your hint. Could you please let me know what you mean with
SER multihomed will not work anymore without forking.
Does multihomed mean one SER is listening to more than one IP addresses?
This is not the case in my scenario.
Does forking only influence the multihomed "mode" or does it also affect
the SER performance or call processing behavior
(e.g. parallel call attempts are being serialized without forking)??
Regards,
Urs Uschmann
You can use fork=no in ser.cfg and it will allow supervise to control
it, the only caveat is that SER can no longer be multihomed when it
doesn't fork. Also since SER only listens on the one interface you need
to make sure it's listening on the correct interface by passing the -l
flag in your run script in the /service directory.
-Evan
On Thu, 2005-01-27 at 18:49 +0100, Jan Janak wrote:
We have been using tool called monit:
http://www.tildeslash.com/monit/
Jan.
On 21-01 15:36, u2 wrote:
> <http://cr.yp.to/djb.html>Hello,
>
> did somebody success to control a SER proxy with D.J. Bernstein's
> daemontools?
> As soon as SER is run, it puts itself to the shell background. As
far as
> I found out, this behavior prevents the
daemontools from
controlling SER.
> What did anybody already experiment with this
toolkit? What do you use
> to control you SER processes (auto-respawn, logging, etc.)?
>
> It would be also great to use Bernstein's multilog to collect SER logs
> in a comfortable manner (with per instance log, log rotation,
> timestamps, etc).
> What do you use here? Any recommendation?
31 Jan
31 Jan
7:41 p.m.
New subject: [Serusers] control SER with D.J. Bernstein's daemontools
That's correct, when you use fork=no ser can only listen on one
interface so if you're trying to use one interface for inbound and a
second for outbound then this will not work but since it sounds like
you're only using a single interface it should work.
Regarding the parallel call attempts I have never tested that when ser
is not forked, it would be something you'd need to test yourself.
-Evan
On Mon, 2005-01-31 at 19:24 +0100, u2 wrote:
Hi,
thanks for your hint. Could you please let me know what you mean with
SER multihomed will not work anymore without forking.
Does multihomed mean one SER is listening to more than one IP addresses?
This is not the case in my scenario.
Does forking only influence the multihomed "mode" or does it also affect
the SER performance or call processing behavior
(e.g. parallel call attempts are being serialized without forking)??
Regards,
Urs Uschmann
You can use fork=no in ser.cfg and it will allow supervise to control
it, the only caveat is that SER can no longer be multihomed when it
doesn't fork. Also since SER only listens on the one interface you need
to make sure it's listening on the correct interface by passing the -l
flag in your run script in the /service directory.
-Evan
On Thu, 2005-01-27 at 18:49 +0100, Jan Janak wrote:
We have been using tool called monit:
http://www.tildeslash.com/monit/
Jan.
On 21-01 15:36, u2 wrote:
> <http://cr.yp.to/djb.html>Hello,
>
> did somebody success to control a SER proxy with D.J. Bernstein's
> daemontools?
> As soon as SER is run, it puts itself to the shell background. As
far as
> I found out, this behavior prevents the
daemontools from
controlling SER.
> > What did anybody already experiment with this toolkit? What do you use
> > to control you SER processes (auto-respawn, logging, etc.)?
> >
> > It would be also great to use Bernstein's multilog to collect SER logs
> > in a comfortable manner (with per instance log, log rotation,
> > timestamps, etc).
> > What do you use here? Any recommendation?
7031
days inactive
7031
days old
1 comments
2 participants
participants (2)
-
Evan Borgstrom -
u2