Cloudron Forum

This should be fixed now with latest package.

Indeed easy to reproduce and a package regression. Working on a fix...

I've reopened our internal issue to adjust the package if possible.

yes @timconsidine is correct. Portainer will not and probably never work or be supported on Cloudron. For a start, Cloudron is not a generic docker image deployment platform. But also even if it would be, then portainer and Cloudron would be at the same level rather than one ontop of the other.

For a start is there anything in the app logs or maybe in the browser console (since you mention a blank start screen after login?)

Also just to be clear, which version of hedgedoc package did you restore to?

Ah no that is correct. Sorry what I meant is, that Cloudron task or app related logs should not show up in default syslog as such, like when you would run journalctl -f However you should have a cloudron-syslog daemon running. Check with systemctl status cloudron-syslog

That one would dump corresponding logs into the correct places in /home/yellowtent/paltformdata/logs/...

So still I am curious how it ends up in /var/log/syslog and then why it would log db dump data there.

That is some good investigation indeed. I tried to reproduce this, but given that Cloudron isn't using syslog as such at all, I am not sure how to reproduce this and what makes it log to syslog in your case. But maybe I am missing something obvious or have you somehow adjusted the docker configs around logging on that instance?

It is not unusual that the memory usage for a service like postgres is filled up. Generally if memory is available it is good to be utilized, however since a database engine doesn't know what else is on the system, we have that limit, otherwise it might just use up everything for caching.

If we have a way to reliably reproduce the issue, we can see if there is a workaround for that S3 provider, but most likely it is some issue on provider end, if this is not happening all the time. Sadly the S3 implementations between provider are not always behaving the same way. We use the AWS S3 SDK for all requests, which is the standard.

Have you by chance edited the config file in /app/data for that instance? Trying to reproduce it here, but it seems it work.

By default Cloudron does not restrict CPU usage per app (unless a limit is manually set). So presumably n8n itself is only single-threaded and thus only uses one CPU core at a time. This would mean you would have to increase the single-core performance of your server instead of adding more cores. This depends on the VPS provider in this case then and is likely not related to Cloudron as such.

For redis, I am not sure how n8n uses redis and if that would improve your situation or if they use it for something which isn't your bottleneck.

Just tried to reproduce this on a fresh penpot instance, but it works here. Are you able to login with OpenId in other apps?

This is solved in Cloudron 9 by virtue of the whole notification view being rewritten and replaced with a popup from navbar. Soon to see the light hopefully.

The system info page shows the data used by the app as such already. This is also much improved in the next Cloudron version.

For the docker image size, this is however something else, since docker shares various image layers between apps, for a start via the cloudron docker base image but also even between app packages, depending on the apps installed and how many same lines in the Dockerfile itself between apps there are. So this is either not trivial or certainly misleading. Either this will show a size much larger if you would add up all the apps (if layers are shared) or if we would somehow count shared layers only towards one installed app, would that one be uninstalled, suddenly another app would take up more space. The overall space all docker images are using is also in the system info page though.

that doesnt really show any errors. Can you clear the settings string $conf['dontlog'] = ''; (remove debug) in the dokuwiki.php file and then login as any admin user (probably some local user which you may have to register directly in dokuwiki and grant admin rights. Then head over to the admin section and the logsviewer there. Now when you try to login with your Cloudron user, something should appear there.

Do you see any errors anywhere? I tried to reproduce the issue with migrating one wiki instance to another, but the login always works here. So I am a bit out of ideas without any errors to work with. I can't quite see how just moving around the document files but not touching any php code or config would somehow end up breaking login.

To be honest the port 8448 shouldn't be mentioned anywhere with federation in such a setup. Not sure where this is coming from nor why somehow port forwarding this would change anything. Something we miss here in your setup which makes a difference then. Overall your instance shows no federation setup issues though from the outside.

The new app package has the default folder set to /app/data so the cli now works out of the box

The vikunja cli tool only works when run from the /app/data directory. So just run:

cd /app/data
vikunja user list

Will see if we can make this the default in the package.

Since you migrated the old wiki into the new instance, what all was copied over there? Were there .php files maybe which could cause this as a side-effect?