Can you check how much memory you are giving the backup task? This is in advanced settings of the backup configuration.
The default would be 400Mb and it will use that amount, since there a fair amount of data piping happening, especially if disk and network I/O are good.
[0.1.3]
@lonkle you can use --skip-reboot to do this.
@d19dotca looks like the system simply runs out of memory and then kills in this case the mysql service. Generally linux will kill a bit at random in such occasions to keep the overall system at least up.
In your case the system itself runs out of memory, regardless what you have set within Cloudron as constraints. The only quick fix is to give the system more physical memory or constrain apps on the system if possible through the Cloudron dashboard. The backup tasks unfortunately always put strain on the whole system in spikes.
I've tried to fix it now, it is currently deployed to our internal instance to see how it behaves, before we make a package release.
@marcusquinn I understand your time constraints, unfortunately I am not able to trigger the behavior you are describing, so this is hard to find a fix for it. Maybe if you have some time, can you describe how one of those apps was setup initially before you adjusted the access control from the groups panel?
@vladimir-d by installing EspoCRM, I was not able to reproduce the mysql requirement for mbind. Not sure what features in EspoCRM then would trigger this to be able to figure out a fix.
Does anyone have more clues about this here?
[0.5.2]
@marcusquinn I am still not sure what to do to see the issue. At least to me this works as expect, but then again this is maybe just because I am used to how it works.
Maybe one oddity of this is, that if an app is setup without restrictions, and then go and configure a group to have access to an app, then for that app all other access is cut off, since it now has restrictions in place to only allow that group. Is this what you hit?
@samir we also went that route initially only to find out that it is more common to migrate between systems, where the UUID in the app database suddenly makes no sense and requires manual migration, compared to username changes. So we had to make some decision which way to go and leaned to the one which is more used in practical terms.
@d19dotca hm since you seem to be receiving SIGKILL signal, this may be that the system as a whole runs out of memory and the kernel starts killing processes to still be able to function.
Check sudo journalctl --system to get more info why SIGKILL was triggered.
[1.164.5]
@michaelpope as long as the block storage can be properly and reliably mounted onto the server and supports common filesystem properties and features, this should work fine.
And just to confirm, moving the app data, does not affect the backups. So apps will still be backed up normally.
[1.13.2]
@atrilahiji yes, we try to package the apps to use the username as identifier. This allows easier migration from one Cloudron to another, or to and from Cloudron, compared to some unique random ID.
However as you found out, this makes username changes hard. Depending on which and how many apps you use, you maybe can tinker with the database.
@side since the office apps are more or less stateless, in the past uninstalling the plugin in nextcloud and installing it fresh has solved some issues. Maybe this helps, but also maybe ask upstream with the Nextcloud community.
[4.12.13]
[1.37.1]
[4.12.12]
@necrevistonnezr not really, this will just not forbid to create PDF thumbnails.
Hi and welcome @mathsoliveira
we currently do not have any specific non-profit plans. Please note that our yearly plan is already 50% discounted and if Cloudron does not suite your needs, we will of course refund within the first month.
Just to give a small update. We have it pinned down to the apache process not serving any more requests. Not sure what the exact issue is, yet.
@webblevince well spotted! I have pushed a new app package which hopefully fixes the issue. I think there are several other apps also being affected by this.
Please check for updates on your instance and apply the update and let us know if this has fixed it for you, then we can go through the other apps to see which one also needs this.
[2.18.4]
[3.10.2]
[1.8.1]
@qimmiq this sounds more like the installation didn't work as expected. Please note that only Ubuntu server is supported in vanilla state, Cloudron will essentially take over the whole system and it is not advised to install anything on the side. In your case I guess the installation of the LAMP stack somehow messed with the Cloudron system, which will have nginx instead of apache running on port 80/443
[1.10.12]
[4.12.11]
@rodber sorry for this taking so long, but I feel we are a bit talking past each other.
To take a step back, on Cloudron all apps run in a read-only filesystem, the app code has to be provided in an immutable image. So an app package must contain all the code already and cannot download or install itself during first run. There is however a read/write folder provided at /app/data mount point if the app needs this. Sometimes those are config files, data or also plugins installed later.
Since you mentioned that both free and paid versions are a different code base, then they also would have to be different app packages currently.
It is not quite clear to me unfortunately what the implications of the various mentioned methods bootstrap/container-builder/custom image/container registry mean in this context. Packages for our users, once published would reside in our company namespace at docker.io to ensure consistency and availability for as long as we support an app.
I will take another look at where we stand currently for the free version as a start residing at https://git.cloudron.io/cloudron/cheveretofree-app
@vladimir-d what is the behavior when the app is frozen? Are requests erroring or are there any errors reported in the browser inspector tools?
@marcusquinn not exactly clear to me what the issue is, at least I am not sure how to reproduce that.
Generally the settings in both users and app configure views edit the same values, so they will overwrite each other.
@marcusquinn there is no beta program. The current rollout is, that we provider updates to all users over a span of a few days to a week, BUT once the release is out, everyone can manually check and thus apply the update.
@vladimir-d according to https://stackoverflow.com/questions/55559386/how-to-fix-mbind-operation-not-permitted-in-mysql-error-log#55706057 it seems some capabilities are not enabled. We generally take a more stripped down approach instead of supporting everything from the get go.
Can you figure out which app triggers this?
@vladimir-d have you tried to restart the app? Otherwise if the problem is still there without any clue in the logs, I guess we have to debug that on your Cloudron directly.
Yes I think this is a great idea, the token currently is anways wrong but makes it work for now. I haven't really invested any time in the externally sharing area, so I think it makes a lot of sense to have a short share URL acting as a token already.
@neurokrish to make it possible to still reach your Cloudron externally, don't rewrite the DNS records as such, however some routers allow for overwriting individual records if you use the DNS server provided via DHCP from your router.
Another more local workaround can be to configure your hosts file on your laptop/PC itself. I don't know how Windows or MacOS handle this but on linux there is a /etc/hosts file where you can hardcode DNS records.
@qimmiq did you visit the setup page via raw IP in the browser? During setup, the Cloudron will only have a self-signed cert without any domain knowledge, even if the DNS already points to that IP.
[4.12.10]
[1.3.9]
[1.14.2]
[3.175.0]
@marcusquinn understood, and the release takes a bit to long also from out perspective, but we also don't want to risk other side-effects by pushing it out prematurely.
[3.10.1]
@deiwee I guess you would want to run it as www-data user though to not mess with file permissions. Did you get any error messages in the log? Of course after app restart it will always take at most a minute to kick the cron according to schedule.
[1.164.4]
[3.174.3]
That is correct, Cloudron only runs on Ubuntu 18.04 or 20.04 generally the distro shouldn't matter for Cloudron users, as we try to make everything possible with the dashboard and Ubuntu was simply chosen, since it is most widely available with VPS providers.