Stuart Henderson wrote:
> Are you monitoring memory usage too? My first instinct is that 2GB feels a
> bit low so I'd want to get some stats on that.
>
> (I have reported these on i386 ports builders from time to time too, I
> can't do much about memory use there though..)
Thanks for the
spammed with 'scsi_xfer pool exhausted'
messages.
Of potential importance is that this is Hetzner CAX11 VPS in
their new region, Hillsboro.
[0]: https://glacier.lgv5.net/tmp/lemon-20230626.png
[1]: https://glacier.lgv5.net/tmp/lemon-20230705.png
How-To-Repeat
ol exhausted'
messages.
Of potential importance is that this is Hetzner CAX11 VPS in
their new region, Hillsboro.
[0]: https://glacier.lgv5.net/tmp/lemon-20230626.png
[1]: https://glacier.lgv5.net/tmp/lemon-20230705.png
>How-To-Repeat:
No clue. Happens
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
It continues to crash rapidly. Up to now crashed 4 times with different
messages.
You may want to read so report is attached.
Thanks,
Valdrin
From: Valdrin MUJA
Sent: Wednesday, July 5, 2023 10:56
To: bugs@openbsd.org
Subject: kernel diagnostic assertion
Hello,
My system hanged with these error messages and gone to ddb.
Here you can find the details. Also crash.txt includes more.
OpenBSD TEST1 7.3 GENERIC.MP#1125 amd64
# sysctl kern.version
kern.version=OpenBSD 7.3 (GENERIC.MP) #1125: Sat Mar 25 10:36:29 MDT 2023
From: Valdrin MUJA
Sent: Wednesday, July 5, 2023 10:56
To: bugs@openbsd.org
Subject: kernel diagnostic assertion "!_kernel_lock_held()" failed
Hello,
My system hanged with these error messages and gone to ddb.
Here you can find the details. Also crash.txt
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':
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():
