* Sebastiaan Couwenberg [2018-08-23 07:13]:
> Are you aware of this issue in NSCA-ng?
No.
> I did not find a link to a bugtracker on nsca-ng.org, so I'm forwarding
> this by email.
I've now enabled the issue tracker on GitHub; if you believe this to be
an upstream bug, feel free to report it th
Just for the record:
* Sebastian Andrzej Siewior [2018-11-05 00:28]:
> It is a TLS1.3 issue. If I limit max protocol to TLS1.2 then the
> testsuite passes.
Yes, it's an OpenSSL bug. If TLSv1.3 is used, SSL_get_psk_identity()¹
unexpectedly returns NULL. I now avoid the function to work around t
* Kurt Roeckx [2019-03-19 22:59]:
> On Tue, Mar 19, 2019 at 10:28:06PM +0100, Holger Weiß wrote:
> > Yes, it's an OpenSSL bug. If TLSv1.3 is used, SSL_get_psk_identity()¹
> > unexpectedly returns NULL. I now avoid the function to work around the
> > issue.
>
>
* Kurt Roeckx [2019-03-20 07:31]:
> On Tue, Mar 19, 2019 at 11:21:19PM +0100, Holger Weiß wrote:
> > * Kurt Roeckx [2019-03-19 22:59]:
> > > On Tue, Mar 19, 2019 at 10:28:06PM +0100, Holger Weiß wrote:
> > > > Yes, it's an OpenSSL bug. If TL
This might be caused by a missing "certs" directory in the OpenSSL
configuration directory as pointed out here:
https://github.com/processone/fast_tls/issues/59#issuecomment-1190378832
Source: dracut
Version: 060+5-8
Followup-For: Bug #1071182
Tags: patch
The following patch addresses the case where /usr and possibly /etc are
mounted read-only in the initrd, and therefore fixes the error messsages
mentioned in my previous email.
From: Holger Weiss
Date: Thu, 30 May 2024 21
Control: reopen -1
Control: tags -1 patch
Just to clarify, the original report mentiones two changes required for
systemd 256:
| 1. systemd 256 makes /usr read-only in initrd:
|- https://github.com/systemd/systemd/issues/32511
|- https://github.com/dracut-ng/dracut-ng/issues/253
|
| 2
* Philipp Huebner [2014-08-19 10:41]:
> Could you please clarify whether this is internal behaviour of ejabberd
> or related to handling the configuration files?
>
> For example, was EJABBERD_NODE previously set (manually / automatically)
> in /etc/default/ejabberd or not?
The wheezy package set
* Alex [2024-11-01 13:29]:
10) systemd eventually times out the start of ejabberd
According to your logs, the actual ejabberd process was started just
fine. However, the systemd unit then calls `ejabberdctl started` in
order to block until startup is completed, and _that_ process hangs.
`
* Soren Stoutner [2025-03-26 16:56]:
I’m raising the severity of this bug as it makes the package
completely unusable.
Installing and running ejabberd 24.12-2 on a fresh trixie system works
just fine for me. So maybe the "grave" severity isn't required here, as
that's meant for bugs that re
* Soren Stoutner [2025-03-28 09:37]:
Has anyone successfully tested an upgrade from 23.10-1? That broke for
me.
We could try to track down the details if you like. I'd start with:
1. Set `loglevel: debug` in `/etc/ejabberd.yml`.
2. systemctl stop ejabberd
3. ejabberdctl foreground
What's t
11 matches
Mail list logo
