@filter i have submitted a PR here - https://github.com/knadh/listmonk/pull/3012
AppDev
Private
Cloudron App Packagers
Posts
-
listmonk: outgoing Message-ID uses localhost.localdomain -
Cal.com closing source@girish I would be surprised if they were to backtrack that move. The developers were always one step towards that direction, they simply used AI scanners as an excuse to close the code earlier (which was arguably pretty much already closed).
It's only a matter of time before the "new" https://github.com/calcom/cal.diy repo gets archived.
-
Could not load dashboard website with loopback check - after 3 triesThis too might be related to the ubuntu kernel issue. Can you check the output of
uname -nar? -
listmonk: outgoing Message-ID uses localhost.localdomain@filter the issue is already there upstream - https://github.com/knadh/listmonk/issues/2898
-
listmonk: outgoing Message-ID uses localhost.localdomain@filter great report. I see the bug even in our current listmonk campaign
I have to investigate what the best way to fix this is. The container name cannot be set to fqdn . This will result in many issues including an app having trouble reaching itself using https://fqdn (because now fqdn will resolve to container IP and bypass nginx and thus have no TLS).
-
Openid-configuration url timeout@tlem4 The dashboard issue is related to the latest ubuntu kernel having a regression. You are running 110 which has a bug . See https://forum.cloudron.io/topic/15265/unusable-application/39
-
Unusable application@james Thanks for the insight. As this is a production server, I'll wait for the update.
Regards. -
Unusable application@james Indeed, the second
curltimes out.But does the original issue from my topic really come from this? I dare have a doubt about it.
As mentioned in a previous reply, the original issue for that other server was solved with the Ubuntu 24 upgrade.
On the other hand, the problem is very much still present on the Cloudron.
Feel free to ask for more debugging cmds. -
Unusable application6.8.0-110-genericMy server's =
110. The other server, without the issue, has the same kernel. -
n8n 2.16.1 has wait node bugMaybe @james has better idea on how we can tackle this in the future. Should we make @package-updates some group instead of the automated user it is now?
