I've synced the expiration now to 7 days to keep changes low until we have a reason to change it
Instead of making it configurable I would prefer a sensible default, since so far no-one else has complained.

Ok, thanks

@girish easy enough!

I think this means that the postgres server ran out of available connection slots in the pool, possibly due to too many clients or buggy clients. Some of those slots are apparently reserved for some admin/superuser connection, I guess to still be able to do maintenance.

Which apps do you have installed which use postgres? (I think you have to dig into the CloudronManifests to figure that)

@brutalbirdie Thank you, I'll give that a shot!

@stoccafisso I think I am able to reproduce this in one of our managed Cloudrons. Looking into the fix.

how embarrassing. You're absolutely right. I was searching after ghosts.

I will mark this as solved for now but also ack that there is possibly some bug either on minio side or Cloudron side.

@vladimir Usually for LAMP app, we tend to create separate apps. i.e LAMP 7.3, 7.4 and in the future 8, are totally separate apps. So, your app won't update automatically.

For addons which are shared across apps, we don't have a way to do this. I guess one idea is to have the app "pin" itself to a specific mysql version and that way we will have multiple mysql databases with different versions running in parallel. Doable but quite complicated! I think @luckow also reported that MySQL 8 broke his drupal app.

Good news is that I don't expect such a big upgrade any time soon.

@girish I guess I'm wondering though why it'd say "Not available yet"... is that because I had restarted the server a few hours earlier? I don't normally notice that though when I restart, it usually still shows data. Is it possible there's a bug here?

If the restarts are losing that data, then I'd think that's a bug, right, if it shows for some services but not all? To me that makes it seems like it's either not completing properly when it runs and that could maybe explain why it shows values for some but not all, or perhaps it's losing data when it should be remembering it. My gut tells me there's a bug here. Or am I way off?

I guess it's okay since we have a workaround to run that command when it happens, my brain is just wondering why it happened in the first place and how it could be prevented.

I got hold of an iPhone temporarily to test this and I've fixed this now with https://git.cloudron.io/cloudron/dashboard/-/commit/ff5ad8b062414d8a972631a19b181c80d2adc15d

Essentially we avoid rendering the native select dropdown button but style it ourselves so we can control also how the dark-mode rendering is done.

@girish yay, thanks for the explanation !

@girish That did the trick. Thanks!

@mastadamus yes 🙂 https://git.cloudron.io/cloudron/box/-/commit/f3d9b8194264469152bc38d24d7080c611784b33

@girish On it.

Neat! This fixed it. Big thanks for the uddate.

@fbartels awesome, thanks for testing. I am fixing the graphite issue, that error is something else. Fixed in https://git.cloudron.io/cloudron/box/-/commit/f7bd47888ac157fc5b86021f6458b6a7f0d3fba8

OK, this got sorted out by enabling basicAuth flag. Thanks for testing @mehdi

Okay... I may be on the side of this working properly again. lol. Maybe I've been wrong this whole time in thinking it wasn't working correctly.

So coincidentally I was checking the mail server logs and saw another example of the same message go through to the same recipient from the same mail server, it was listed in the logs as "just now" so I quickly checked mxtoolbox and found that only 4 at that time had been listed, none of which were ones I was using.

Here is how it looked at the very moment I checked when it was "just now" in the logs:

69bc5a02-12ca-420e-958a-27405c21f7ed-image.png

07b937c4-4840-4c14-887b-7513acc87251-image.png

Edit: Checking about 6 minutes later, I see the blocklists have aleady been updated for more (Spamhaus Zen in this case would have caught it if it were about 5 minutes earlier):

4522d168-dc21-498f-845b-885cfe0a73a1-image.png

So I guess we can probably mark this as resolved, as I now see conclusive evidence that the various blocklists used just didn't have it listed until a few minutes after the message was received. I guess in order for it to adapt so quickly this spam attack on one of my users from those mail servers must be right at the beginning of a spam wave. Kind of neat actually to see how real-time these lists are. haha.

I think one idea is to patch the user ids to match the existing cloudron user ids (in the database directly). I don't know if this will work, but I am just trying this out with @yusf and will report back.

@brutalbirdie OK, because Cloudron doesn't mariadb (only mysql). You can remove it from the source list.

@imc67 said in Updating FreeScout failed:

@girish said in Updating FreeScout failed:

@imc67 there is a bug here . Can you apply this one liner and then set the memory limit https://git.cloudron.io/cloudron/box/-/commit/750f313c6a36d8d961892df4a41cb7c41faa1f1b ? You have systemctl restart box after you change that line in /home/yellowtent/box/src/apps.js.

Will try this in a few hours

@girish this solved the bug, thanks!

@freetommy If I understand you correctly, what you are saying is that when email forwarding is enabled in rainloop, then the forwarding is done directly to the destination domain via port 25 instead of using Cloudron's email relay. Did I get that right?

@eyecreate ah good catch about the .initialized file, I've adjusted my snippet.

@girish
Many thanks.

My mistake, I was so convinced auto-update was running that I didn't notice.

After updating to latest Cloudron version, all problems have resolved 👍

Thanks again
T.

Fixed this. My IP address changed and I forgot to whitelist my new IP for NameCheap.

@nebulon I thought it was perhaps the Broken Links Checker on one of my WordPress installs, as as @marcusquinn noted it's widely known to sometimes cause such issues, but I've disabled that and I'm still getting these /mysql was restarted (OOM) (although they don't seem to appear in the event log?).

I note that the most recent one happened 5 minutes after my backups are due to start, and the other previous two times it's been 7-9mins before updates are due to run.

I wonder if either of those (backup/ update) processes might have something to do with it?

I guess I could just give mysql more memory and not worry, but be nice to know what's happening and why...

@anwarnajjar You can set this as a rule in your Cloud firewall. Cloudron itself doesn't have built-in support for this yet. For example, in DO, you can use their firewall - https://www.digitalocean.com/docs/networking/firewalls/how-to/configure-rules/

@robi is right. @ryan can you send us an email to support@ to move your plan to a free plan. Currently, we have to do this manually i.e move something from a paid plan (even if cancelled) -> free plan.

@d19dotca since the email is forwarded , this info is probably lost. One idea is to look into the bounce mail headers. Maybe there is some message I'd or something we can match.

@drpaneas Just give that redis more memory. The "e1ca318a" is the app id. If you put in the search in the apps view, you will know which app's redis needs a bit more memory. It was reported earlier that pixelfed's redis needs more memory after the update. I guess this is because of update to Redis 5.