Cloudron Forum

I get similar to @ruihildt despite the OOM fix by @James

@LoudLemur thanks - will look into it

@james thank you, I appreciate you looking into and resolving it

Appreciate that mail is the focus of 9.2, but maybe you can sneak in a minor enhancement to Notifications :
From :
'Grafana at grafana.appx.uk updated to package version 2.5.1'
To :
'UPDATED Grafana at grafana.appx.uk to package version 2.5.1'
Speeds user review of notifications

Cloudron Team : I am not clear whether cloudron 3.24.0 used a different upstream base 3.1.0 to previous, but my impression is not. So the issue is in cloudron v3.24.0 ? Can it be fixed ?

Never had a problem with Umami before.
I had it set at 2Gb RAM which is a healthy amount for this kind of app (even maybe high).
Auto-upgrade to Cloudron v3.24.0 immediately brought repeat OOM
Increased it - reluctantly - to 3Gb.
Still crashing.

Checked redid for umami - running at 15% (40/256) - restarted it anyway.

Now umami is not responding.

Anyone else seeing this ?
Don't see any relevant GitHub issues for upstream 3.1.0

@LoudLemur well done, sounds like you have had fun (!).

I'm not clear. You mentioned your production system - is that your own build or using my ALPHA community app ? Or you already cloned/fixed mine ?

If the latter, I can try to make changes as you describe. But I am in the middle of a couple of big projects, so it won't be immediate.

If timing is an issue, you might want to clone/fix and publish your own repo/community app.

I thought I was imagining it, but fairly certain that I am not.

• Working on an app using CloudronVersions to publish, suddenly the app would not update in the Cloudron dashboard.
• CloudronVersions.json is ~1600 lines long, from 0.0.1 to 0.7.5, jumping a few so about 60 versions
• on last update CloudronVersions.json "lost" versions 0.7.2, 0.7.3 and 0.7.4 (and who knows what from earlier in the chain), so app running last version 0.7.4 would not find/recognise 0.7.5 as an upgrade
• fixed by deleting versions 0.0.1 through 0.7.0 to shrink the file, copying 0.7.1 to 0.7.4 and manually editing values
• app then says 'oooo, I see I am on 0.7.4 and found 0.7.4', and allows me to upgrade to latest 0.7.5
• my build cycle is automated, I never touch CloudronVersions.json

Maybe lazy layman's diagnosis : some CLI bug in cloudron versions add loses content in Versions while adding a new one. Triggered by length limit or buffer constraint ?

Not a problem as such, as I now know how to fix it.
Surfacing this in case others come across it, maybe Cloudron team can check it when no other pressing tasks.

@scooke didn't Andreas make it into a community app ?

@LoudLemur of course, your decision. I don't it needed killing, it could be a useful tool, just not auto-post or bulk-post its findings.

Packaged

@LoudLemur also already packaged as community app
If you don’t check before posting, you risk becoming a bot posting slop

@LoudLemur “just packaged it” - seems a decade ago in my butterfly mind
I don’t think it was as hard as your summary suggests
The hard work is in populating the content and framework docs. I didn’t have a use case for it so I didn’t get into that.
The packaging code is there if you want to clone and develop further - my project list is a little full but will bear this in mind if I need a diversion

@James thank you
I had not initially intended to use CloudronVersions in this way, but it is a real time saver.

Yep, once an app is published, probably no trimming (unless very old revoked versions).

The new Community App functionality is a real bonus, so thanks once more to the Cloudron team for implementing it.

The app update functionality provided (new entry in CloudronVersions.json) really helps with the build cycle, testing changes etc., without time-consuming repeat setup of app environment etc, before it even gets to a MVP release stage.

However that does result in a quite big CloudronVersion.json - on one app in dev, it is 60kb. Not a problem as such. But I wonder if we really need to keep such a big history of the app's dev cycle, 0.0.1, 0.0.2 etc all the way up to say 1.0.0 and beyond. Especially when the older entries become redundant by being explicitly revoked or by representing early prototyping with breaking changes.

I have tested just trimming CloudronVersions.json, removing early entries. It seems to have no ill effects providing the json structure is honoured. So my intention is to prune the versions file of dev release before an app becomes released.

So in terms of managing CloudronVersions.json, I'm interested in Cloudron team's thoughts or any advice.
Maybe you did not expect the functionality to be used like, so did not expect a large versions file. But I can easily see it growing to to 200k in some cases. Not a problem technically, but nevertheless ...

Simple solution : change 'Uninstall' to 'Manage' or 'Stop/Uninstall' or '....'

The column width longest label is 'Access Control' so providing the new label is <= to that, UI works.

Still a little unsure about this.
If the Garage app is storing large volumes, say 5Gb, is backup by tarball appropriate, do we want to be facilitating that ?
That said, I guess it still needs fixing for smaller tarballs.

@jadudm thanks for the clarification
will certainly bear that in mind for future issues

for this one on my Garage app, I'm not sure what to do. If an App Store version is coming, even unstable, that might be better for this wanting Garage.

I will try find time to check out my Garage packaging code with this issue in mind.

@d19dotca errr...

No I have not experienced that.
Personally I use rsync not tarball.
I will try a tarball backup later.

If it's a backup issue, is it an app issue ?
I don't understand this.

EDIT : that's meant as unhelpful, just not sure where to start looking - will ask AI
But did you see that an official version is close ?

https://forum.cloudron.io/post/122927

Interesting questions. I shall be watching hing for answers - wished I had them.