Hello Giannis,
can you give a try diff below? it is against current, but it should
apply to 7.3 too.
the change makes pf(4) to honor PERSISTENT flag set by pfctl command
line tool as well as relayd. PERISTENT flag makes tables to survive
rules clenup. It should prevent tables created by relayd to
Hello Giannis,
On Thu, Jul 06, 2023 at 01:54:36PM +0300, Kapetanakis Giannis wrote:
>
> Hi sashan,
>
> Your logic seems fine to me. Indeed it acts like they are persistent. They
> don't have the p flag.
>
> # pfctl -a 'relayd/dir-imap' -sT -vg
> --a-r-- dir-imap?? relayd/dir-imap
On 06/07/2023 12:59, Alexandr Nedvedicky wrote:
> Hello,
>
>
> On Wed, Jul 05, 2023 at 03:33:36PM +0300, Kapetanakis Giannis wrote:
>> In any case we shouldn't get table statistics for tables that are down.
>>
>> log_debug are just added by for my debugging, but the
>> if (!rdr->table->up) continue
Hello,
On Wed, Jul 05, 2023 at 03:33:36PM +0300, Kapetanakis Giannis wrote:
> In any case we shouldn't get table statistics for tables that are down.
>
> log_debug are just added by for my debugging, but the
> if (!rdr->table->up) continue;
> should probably go in.
>
> G
>
> Index: pfe.c
> ==
Updates:
1) I've managed to exit the backup firewall
2) adding -d -vvv
didn't print any more log_debug concerning our fatal() on table stats
it did print other log_debug but not from the shutdown() path.
it exited again with only printing:
pfe: check_table: cannot get table stats for dir2-lmtp
Hello,
On Wed, Jul 05, 2023 at 11:36:26AM +0300, Kapetanakis Giannis wrote:
> Tried to replicate the issue today with running relayd in debug mode in order
> to print more details.
>
> /usr/sbin/relayd -d -v
I did poke to sources. try to increase verbosity by using more 'v':
/usr/s
Tried to replicate the issue today with running relayd in debug mode in order
to print more details.
/usr/sbin/relayd -d -v
when relayd exited it only printed:
pfe: check_table: cannot get table stats for dir-sieve@relayd/dir-sieve: No
such file or directory
nothing from:
kill_tables():
log_de
On 04/07/2023 19:13, Kapetanakis Giannis wrote:
On 03/07/2023 19:18, Alexandr Nedvedicky wrote:
8<---8<---8<--8<
diff --git a/usr.sbin/relayd/pfe.c b/usr.sbin/relayd/pfe.c
index 3a97b749c4b..ad9c9cdc0cc 100644
--- a/usr.sbin/relayd/pfe.c
++
On 03/07/2023 19:18, Alexandr Nedvedicky wrote:
8<---8<---8<--8<
diff --git a/usr.sbin/relayd/pfe.c b/usr.sbin/relayd/pfe.c
index 3a97b749c4b..ad9c9cdc0cc 100644
--- a/usr.sbin/relayd/pfe.c
+++ b/usr.sbin/relayd/pfe.c
@@ -93,6 +93,7 @@ pfe_i
On 04/07/2023 11:45, Alexandr Nedvedicky wrote:
> Hello,
>
> On Tue, Jul 04, 2023 at 11:22:34AM +0300, Kapetanakis Giannis wrote:
>> Hello,
>>
>> I will try your diff, but since I have to completely turn off mail service
>> it might take a while.
>>
>> Meanwhile, just a wild guess from my side, al
Hello,
On Tue, Jul 04, 2023 at 11:22:34AM +0300, Kapetanakis Giannis wrote:
> Hello,
>
> I will try your diff, but since I have to completely turn off mail service it
> might take a while.
>
> Meanwhile, just a wild guess from my side, although I'm not a dev:
>
> It seems to me that a table is
Hello,
I will try your diff, but since I have to completely turn off mail service it
might take a while.
Meanwhile, just a wild guess from my side, although I'm not a dev:
It seems to me that a table is being removed, specifically the table that has
the hosts for the redirect.
It's like after
Hello,
I took a closer look at relayd logs you obtained and tried to locate
the origin of those messages in source code. the exact mechanism is
still mystery to me.
I'll start with brief summary:
> Jun 30 01:47:46 ll1 relayd[61766]: pfe: check_table: cannot get table stats:
> No such file or di
ok managed to trigger it again:
Jun 30 14:06:45 ll1 relayd[23378]: pfe: check_table: cannot get table stats for
dir-sieve@relayd/dir-sieve: No such file or directory
anchors-pre-error:
relayd
relayd/dir-imap
relayd/dir-lmtp
relayd/dir-pop
relayd/dir-sieve
relayd/dns
relayd/dns_tls
On Fri, Jun 30, 2023 at 01:31:50PM +0300, Kapetanakis Giannis wrote:
> The program does not terminate by system.
>
> It indeed exits from that fatal() function in check_table()
>
> I will add the table print and try to reproduce at some time. It might take a
> while cause I have to shutdown comp
On Fri, Jun 30, 2023 at 01:31:50PM +0300, Kapetanakis Giannis wrote:
> The program does not terminate by system.
>
> It indeed exits from that fatal() function in check_table()
>
> I will add the table print and try to reproduce at some time. It might take a
> while cause I have to shutdown comp
Probably the latest libutil cause of ibuf_data()
will test and report.
thanx,
G
On 30/06/2023 13:31, Kapetanakis Giannis wrote:
> The program does not terminate by system.
>
> It indeed exits from that fatal() function in check_table()
>
> I will add the table print and try to reproduce at some
The program does not terminate by system.
It indeed exits from that fatal() function in check_table()
I will add the table print and try to reproduce at some time. It might take a
while cause I have to shutdown completely our mail for this to test.
Will report back.
Does it need to build with
On Fri, Jun 30, 2023 at 11:57:06AM +0200, Alexandr Nedvedicky wrote:
> Hello,
>
> I'm not familiar enough with relayd, so perhaps other folks
> here might provide better way to troubleshoot the issue.
>
> On Fri, Jun 30, 2023 at 11:10:44AM +0300, Kapetanakis Giannis wrote:
> > Hello,
> >
> > This
Hello,
I'm not familiar enough with relayd, so perhaps other folks
here might provide better way to troubleshoot the issue.
On Fri, Jun 30, 2023 at 11:10:44AM +0300, Kapetanakis Giannis wrote:
> Hello,
>
> This happened to me twice.
> OpenBSD 7.3 with syspatches.
>
> I have a pair of carp/pfsync/
20 matches
Mail list logo
