Re: OpenBSD 6.1: relayd does not start more than 3 processes

2017-05-05 Thread Hiltjo Posthuma
On Fri, May 05, 2017 at 04:33:02PM +0200, Florian Ermisch wrote:
> 
> 
> Am 5. Mai 2017 16:05:09 MESZ schrieb Maxim Bourmistrov 
> :
> >
> >> 5 maj 2017 kl. 15:55 skrev Maxim Bourmistrov
> >:
> >> 
> >> 
> >>> 5 maj 2017 kl. 14:41 skrev Hiltjo Posthuma :
> >>> 
> >>> On Fri, May 05, 2017 at 12:30:56PM +0200, Maxim Bourmistrov wrote:
>  […] 
>  Changing ’prefork’ from 15 to 3 makes it work.
>  
>  Is this a bug?
>  
>  Br
> >>> 
> >>> Hey,
> >>> 
> >>> This is a random guess since you haven't posted the whole config,
> >>> but I think
> >>> it has bitten me too sometime:
> >>> 
> >>> Do you have the global options such as prefork defined before your
> >>> relays and routes or not?
> >>> 
> >>> The order of the global options matter. If the global options are
> >>> set after
> >>> the table they are not initialized on the tables and can actually
> >>> crash relayd.
> >>> This is because the health checking uses a different prefork value
> >and checks
> >>> the "wrong" amount.
> >>> 
> >>> I'm not sure, but I think it is not a bug: it is documented in
> >>> relayd.conf(5).
> >>> 
> >>> Thinking about it: would it be acceptable if `relayd -n` shows a
> >>> warning if
> >>> global options are defined in the wrong order? I can write the patch
> >>> for it
> >>> if it makes sense.
> >>> 
> >>> I hope this helps you in some way,
> >>> 
> >>> -- 
> >>> Kind regards,
> >>> Hiltjo
> >> 
> >> The whole config is like this:
> >> 
> >> […]
> >> 
> >> Note, config layout exactly the same which runs already on
> >6.0-stable.
> >> 
> >> My original question is why I can’t fork more than 3 procs any more
> >> and why relayd starts then prefork > 3
> >> and does not do a health check.
> >> 
> >> Br
> >
> >Hm, I tried this out - re-ordering the layout of the config.
> >You are, indeed, correct here.
> >
> >Strange that this runs on 6.0.
> >
> >Case closed.
> >Sorry for the noise.
> >
> >Br
> 
> I would still say it's worth the patch
> Hiltjo offered to write. Or At least have
> the warning printed when testing the
> config with `-v -n`.
> 
> Regards, Florian
> 

An idea:

Maybe in parse.y in the main rule it can be checked something like this:

if (last_table_id || last_host_id || last_relay_id ||
last_proto_id || last_rt_id || last_nr_id ||
last_key_id) {
yyerror("global option used after non-global option");
YYERROR;
}

Sorry, I'm not a yacc guru :)

-- 
Kind regards,
Hiltjo



Re: OpenBSD 6.1: relayd does not start more than 3 processes

2017-05-05 Thread Andre Ruppert

Hm, I got a relayd-problem with a similar config.

100% CPU load nearly all 10 days with 5.9,
same behavior all 3-4 weeks with 6.0.

Wrong-ordered relayd.conf too.

looks like this when running in trouble:

_relayd  33851 100.0  0.1  2004  4496 ??  Rp15Apr17  3363:59.52 
relayd: relay (relayd)
_relayd  94800  0.0  0.1  2208  4720 ??  Sp15Apr171:01.44 
relayd: relay (relayd)
root 92841  0.0  0.1  1724  3996 ??  Is15Apr170:01.70 
/usr/sbin/relayd -v
_relayd  65955  0.0  0.1  1328  3436 ??  Sp15Apr170:11.41 
relayd: pfe (relayd)
_relayd  40687  0.0  0.1  1240  3264 ??  Sp15Apr170:28.04 
relayd: hce (relayd)
_relayd  75933  0.0  0.1  1220  3404 ??  Ip15Apr170:37.44 
relayd: ca (relayd)
_relayd  82476  0.0  0.1  1216  3304 ??  Ip15Apr170:35.52 
relayd: ca (relayd)


I just re-ordered my config.

No let's see if it still comes to trouble in the next weeks... ;-)

Andre

Am 05.05.17 um 16:05 schrieb Maxim Bourmistrov:


Hm, I tried this out - re-ordering the layout of the config.
You are, indeed, correct here.

Strange that this runs on 6.0.

Case closed.
Sorry for the noise.

Br





smime.p7s
Description: S/MIME Cryptographic Signature


Re: OpenBSD 6.1: relayd does not start more than 3 processes

2017-05-05 Thread Florian Ermisch


Am 5. Mai 2017 16:05:09 MESZ schrieb Maxim Bourmistrov 
:
>
>> 5 maj 2017 kl. 15:55 skrev Maxim Bourmistrov
>:
>> 
>> 
>>> 5 maj 2017 kl. 14:41 skrev Hiltjo Posthuma :
>>> 
>>> On Fri, May 05, 2017 at 12:30:56PM +0200, Maxim Bourmistrov wrote:
 […] 
 Changing ’prefork’ from 15 to 3 makes it work.
 
 Is this a bug?
 
 Br
>>> 
>>> Hey,
>>> 
>>> This is a random guess since you haven't posted the whole config,
>>> but I think
>>> it has bitten me too sometime:
>>> 
>>> Do you have the global options such as prefork defined before your
>>> relays and routes or not?
>>> 
>>> The order of the global options matter. If the global options are
>>> set after
>>> the table they are not initialized on the tables and can actually
>>> crash relayd.
>>> This is because the health checking uses a different prefork value
>and checks
>>> the "wrong" amount.
>>> 
>>> I'm not sure, but I think it is not a bug: it is documented in
>>> relayd.conf(5).
>>> 
>>> Thinking about it: would it be acceptable if `relayd -n` shows a
>>> warning if
>>> global options are defined in the wrong order? I can write the patch
>>> for it
>>> if it makes sense.
>>> 
>>> I hope this helps you in some way,
>>> 
>>> -- 
>>> Kind regards,
>>> Hiltjo
>> 
>> The whole config is like this:
>> 
>> […]
>> 
>> Note, config layout exactly the same which runs already on
>6.0-stable.
>> 
>> My original question is why I can’t fork more than 3 procs any more
>> and why relayd starts then prefork > 3
>> and does not do a health check.
>> 
>> Br
>
>Hm, I tried this out - re-ordering the layout of the config.
>You are, indeed, correct here.
>
>Strange that this runs on 6.0.
>
>Case closed.
>Sorry for the noise.
>
>Br

I would still say it's worth the patch
Hiltjo offered to write. Or At least have
the warning printed when testing the
config with `-v -n`.

Regards, Florian



Re: OpenBSD 6.1: relayd does not start more than 3 processes

2017-05-05 Thread Maxim Bourmistrov

> 5 maj 2017 kl. 15:55 skrev Maxim Bourmistrov :
> 
> 
>> 5 maj 2017 kl. 14:41 skrev Hiltjo Posthuma :
>> 
>> On Fri, May 05, 2017 at 12:30:56PM +0200, Maxim Bourmistrov wrote:
>>> 
>>> Hey,
>>> on OpenBSD 6.0-stable I have following configuration for relayd:
>>> 
>>> snip———
>>> interval 10
>>> timeout 1200
>>> prefork 15
>>> log all
>>> ——
>>> 
>>> Respective login.conf to spawn more relayd procs:
>>> 
>>> relayd:\
>>>   :maxproc-max=31:\
>>>   :maxproc-cur=15:\
>>>   :openfiles=65536:\
>>>   :tc=daemon:
>>> 
>>> 
>>> With config options above moved to a 6.1 creates following:
>>> 
>>> relayd starts but brings up no more that 3 relay-processes.
>>> Also after start up it refuses to do any checks configured (in my simple 
>>> test I used check tcp) 
>>> 
>>> [mxb-test]-[12:21:41]# relayctl sh su
>>> Id  TypeNameAvlblty Status
>>> 1   relay   rabbitmqactive
>>> 1   table   rabbitmqpool:5672   empty
>>> 1   host10.5.96.8   unknown
>>> 2   table   rabbitmqfallback:5672   empty
>>> 2   host10.5.96.9   unknown
>>> 
>>> 
>>> Changing ’prefork’ from 15 to 3 makes it work.
>>> 
>>> Is this a bug?
>>> 
>>> Br
>>> 
>>> 
>>> 
>> 
>> Hey,
>> 
>> This is a random guess since you haven't posted the whole config, but I think
>> it has bitten me too sometime:
>> 
>> Do you have the global options such as prefork defined before your
>> relays and routes or not?
>> 
>> The order of the global options matter. If the global options are set after
>> the table they are not initialized on the tables and can actually crash 
>> relayd.
>> This is because the health checking uses a different prefork value and checks
>> the "wrong" amount.
>> 
>> I'm not sure, but I think it is not a bug: it is documented in 
>> relayd.conf(5).
>> 
>> Thinking about it: would it be acceptable if `relayd -n` shows a warning if
>> global options are defined in the wrong order? I can write the patch for it
>> if it makes sense.
>> 
>> I hope this helps you in some way,
>> 
>> -- 
>> Kind regards,
>> Hiltjo
> 
> The whole config is like this:
> 
> include "/etc/pj/nz/akl1/shared/pf/int/networks"
> include "/etc/pj/nz/akl1/shared/pf/int/common_tables"
> 
> interval 10
> timeout 1000
> prefork 3 #15
> log all
> 
> #include "/etc/pj/shared/relayd/protocols"
> 
> tcp protocol tcp_proto {
>tcp { nodelay, sack, socket buffer 65536, backlog 128 }
> }
> 
> relay rabbitmq {
>listen on 10.5.128.16 port 5674
> #protocol tcp_proto
> #   session timeout 10800
>forward to  port 5672 mode roundrobin check tcp
>forward to  port 5672 mode roundrobin check tcp
> }
> 
> Tables are shared with PF so I don’t have to re-define those.
> ”common_tables” in config contains:
> 
> table  { $RMQ1_VLAN302 }
> table  { $RMQ2_VLAN302 }
> 
> I seems not be able to find a place in manage were it states that global 
> options need to go before
> table definitions. 
> 
> Note, config layout exactly the same which runs already on 6.0-stable.
> 
> My original question is why I can’t fork more than 3 procs any more
> and why relayd starts then prefork > 3 and does not do a health check.
> 
> Br

Hm, I tried this out - re-ordering the layout of the config.
You are, indeed, correct here.

Strange that this runs on 6.0.

Case closed.
Sorry for the noise.

Br



Re: OpenBSD 6.1: relayd does not start more than 3 processes

2017-05-05 Thread Maxim Bourmistrov

> 5 maj 2017 kl. 14:41 skrev Hiltjo Posthuma :
> 
> On Fri, May 05, 2017 at 12:30:56PM +0200, Maxim Bourmistrov wrote:
>> 
>> Hey,
>> on OpenBSD 6.0-stable I have following configuration for relayd:
>> 
>> snip———
>> interval 10
>> timeout 1200
>> prefork 15
>> log all
>> ——
>> 
>> Respective login.conf to spawn more relayd procs:
>> 
>> relayd:\
>>:maxproc-max=31:\
>>:maxproc-cur=15:\
>>:openfiles=65536:\
>>:tc=daemon:
>> 
>> 
>> With config options above moved to a 6.1 creates following:
>> 
>> relayd starts but brings up no more that 3 relay-processes.
>> Also after start up it refuses to do any checks configured (in my simple 
>> test I used check tcp) 
>> 
>> [mxb-test]-[12:21:41]# relayctl sh su
>> Id  TypeNameAvlblty Status
>> 1   relay   rabbitmqactive
>> 1   table   rabbitmqpool:5672   empty
>> 1   host10.5.96.8   unknown
>> 2   table   rabbitmqfallback:5672   empty
>> 2   host10.5.96.9   unknown
>> 
>> 
>> Changing ’prefork’ from 15 to 3 makes it work.
>> 
>> Is this a bug?
>> 
>> Br
>> 
>> 
>> 
> 
> Hey,
> 
> This is a random guess since you haven't posted the whole config, but I think
> it has bitten me too sometime:
> 
> Do you have the global options such as prefork defined before your
> relays and routes or not?
> 
> The order of the global options matter. If the global options are set after
> the table they are not initialized on the tables and can actually crash 
> relayd.
> This is because the health checking uses a different prefork value and checks
> the "wrong" amount.
> 
> I'm not sure, but I think it is not a bug: it is documented in relayd.conf(5).
> 
> Thinking about it: would it be acceptable if `relayd -n` shows a warning if
> global options are defined in the wrong order? I can write the patch for it
> if it makes sense.
> 
> I hope this helps you in some way,
> 
> -- 
> Kind regards,
> Hiltjo

The whole config is like this:

include "/etc/pj/nz/akl1/shared/pf/int/networks"
include "/etc/pj/nz/akl1/shared/pf/int/common_tables"

interval 10
timeout 1000
prefork 3 #15
log all

#include "/etc/pj/shared/relayd/protocols"

tcp protocol tcp_proto {
tcp { nodelay, sack, socket buffer 65536, backlog 128 }
}

relay rabbitmq {
listen on 10.5.128.16 port 5674
#protocol tcp_proto
#   session timeout 10800
forward to  port 5672 mode roundrobin check tcp
forward to  port 5672 mode roundrobin check tcp
}

Tables are shared with PF so I don’t have to re-define those.
”common_tables” in config contains:

table  { $RMQ1_VLAN302 }
table  { $RMQ2_VLAN302 }

I seems not be able to find a place in manage were it states that global 
options need to go before
table definitions. 

Note, config layout exactly the same which runs already on 6.0-stable.

My original question is why I can’t fork more than 3 procs any more
and why relayd starts then prefork > 3 and does not do a health check.

Br
 


Re: OpenBSD 6.1: relayd does not start more than 3 processes

2017-05-05 Thread Hiltjo Posthuma
On Fri, May 05, 2017 at 12:30:56PM +0200, Maxim Bourmistrov wrote:
> 
> Hey,
> on OpenBSD 6.0-stable I have following configuration for relayd:
> 
> snip———
> interval 10
> timeout 1200
> prefork 15
> log all
> ——
>  
> Respective login.conf to spawn more relayd procs:
> 
> relayd:\
> :maxproc-max=31:\
> :maxproc-cur=15:\
> :openfiles=65536:\
> :tc=daemon:
> 
> 
> With config options above moved to a 6.1 creates following:
> 
> relayd starts but brings up no more that 3 relay-processes.
> Also after start up it refuses to do any checks configured (in my simple test 
> I used check tcp) 
> 
> [mxb-test]-[12:21:41]# relayctl sh su
> Id  TypeNameAvlblty Status
> 1   relay   rabbitmqactive
> 1   table   rabbitmqpool:5672   empty
> 1   host10.5.96.8   unknown
> 2   table   rabbitmqfallback:5672   empty
> 2   host10.5.96.9   unknown
> 
> 
> Changing ’prefork’ from 15 to 3 makes it work.
> 
> Is this a bug?
> 
> Br
> 
> 
> 

Hey,

This is a random guess since you haven't posted the whole config, but I think
it has bitten me too sometime:

Do you have the global options such as prefork defined before your
relays and routes or not?

The order of the global options matter. If the global options are set after
the table they are not initialized on the tables and can actually crash relayd.
This is because the health checking uses a different prefork value and checks
the "wrong" amount.

I'm not sure, but I think it is not a bug: it is documented in relayd.conf(5).

Thinking about it: would it be acceptable if `relayd -n` shows a warning if
global options are defined in the wrong order? I can write the patch for it
if it makes sense.

I hope this helps you in some way,

-- 
Kind regards,
Hiltjo



OpenBSD 6.1: relayd does not start more than 3 processes

2017-05-05 Thread Maxim Bourmistrov

Hey,
on OpenBSD 6.0-stable I have following configuration for relayd:

snip———
interval 10
timeout 1200
prefork 15
log all
——
 
Respective login.conf to spawn more relayd procs:

relayd:\
:maxproc-max=31:\
:maxproc-cur=15:\
:openfiles=65536:\
:tc=daemon:


With config options above moved to a 6.1 creates following:

relayd starts but brings up no more that 3 relay-processes.
Also after start up it refuses to do any checks configured (in my simple test I 
used check tcp) 

[mxb-test]-[12:21:41]# relayctl sh su
Id  TypeNameAvlblty Status
1   relay   rabbitmqactive
1   table   rabbitmqpool:5672   empty
1   host10.5.96.8   unknown
2   table   rabbitmqfallback:5672   empty
2   host10.5.96.9   unknown


Changing ’prefork’ from 15 to 3 makes it work.

Is this a bug?

Br