@girish Thank you. The Red Hat documentation was roughly how I was thinking of it and in that case I should be fine with 1GB of swap (as I am not suspending the server, etc...) although 2GB might be better.

However, if i look at my apps they say, "Cloudron allocates 50% of this value as RAM and 50% as swap.". If that is a hard rule then that might explain why my apps seem to be restarting, even ones that don't get a huge amount of load (eg; low visit website), as after 8 x 256mb apps my swap space is fully allocated.

Now, I am running 17 apps at the moment and according to System Info/System Memory this is using 3GB of memory out of "RAM (3.85 GB) + Swap (984.99 MB)" which would seem to me to be a reasonable headroom unless the swap rule is hard at which point I have (assuming 256mb apps) over 2GB allocated to swap and under 1GB available.

So, is the swap rule hard? Because then it would seem to me to mean I need to have the same amount of swap as RAM. In my case 4GB.

Hopefully that is clear and thank you for your former reply.

Weirdly, I have just been looking at libretime to set up a radio station with a friend. It would be cool to have it on Cloudron (and easier).

@jeau https://github.com/ned-kelly/docker-multicontainer-libretime/blob/master/README.md

@girish Increasing the swap seems to have cured the problem. Additionally, there may have been a problem caused by a misreading of the amount of swap as originally on the Linode it said there was only 512mb but in Cloudron it said there was almost 1GB.

I have increased the swap from 512mb to 2048mb and I haven't received any app out of memory notifications since then so that seems to have cured it.

Thank you for your help.

@jdaviescoates I looked but there didn't seem to be any multiperson ones that could pump out an mp3 stream. I have another look though. Thank you.

@jdaviescoates Will do, and vice versa.

@echokos Did youcome up with an answer to this. I am looking to do the same and I can deploy a LAMP stack or Surfer to do a single static site but at a cost of 256MB each. What I would like is to be able to use one Surfer or LAMP stack to serve many domains.

EG; 10 x static sites = 2560MB of usage in Cloudron whereas anywhere else I can serve 10 static sites with less that half that.

@masonbee Re: Email authentication failure

Solved. Duh, I changed my password and never realised the emails weren't on independent passwords.

@subven Mail server domain is the same, I checked that.

I didn't try roundcube but I did try rainloop yesterday when sogo wasn't working. No go.

I tried restarting the server.

The logs make no sense to me. If I refresh an address in Thunderbird the logs don't have my ip address or domain (except kubuntu.info) in them but there is another one that is listed by spamhaus and the rdns on the others is nxdomain...bizzare.

Here is an example

As of yesterday none of my email accounts on the Cloudron accept authentication. This is happening on multiple computers using different clients (Thunderbird, Kmail) and possibly happened after trying to install Sogo yesterday. It is also happened simultaneously across six different email accounts.

I can send email though.

According to Email settings - all the accounts are green., domain is correct, there is enough space.

According to the event log - the only things that happened that was usual was installing sogo and then changing its domain from mail.xxx.xxx to webmail.xxx.xxx but it wasn't working on mail.xxx.xxx to begin with.

There were other things installed an uninstalled but nothing to do with mail but previous to sogo I tried to install lychee which worked the first time but then failed to find the api on a second install.

Any ideas?

@jdaviescoates Will do, and vice versa.

@girish Can you add in that you have to restart the app to make it read the new password.

This might be outside the scope of Cloudron as it is a two application process but there is a multi network opensource application called Ferdi that relies on a server to hold the passwords and such.

Having the server available on Cloudron would enable people to have a multimessenger application where they are not giving away their passwords to be held by an unknown server/admin.

There is a docker setup here.

@jdaviescoates I looked but there didn't seem to be any multiperson ones that could pump out an mp3 stream. I have another look though. Thank you.

Weirdly, I have just been looking at libretime to set up a radio station with a friend. It would be cool to have it on Cloudron (and easier).

@jeau https://github.com/ned-kelly/docker-multicontainer-libretime/blob/master/README.md

@girish Increasing the swap seems to have cured the problem. Additionally, there may have been a problem caused by a misreading of the amount of swap as originally on the Linode it said there was only 512mb but in Cloudron it said there was almost 1GB.

I have increased the swap from 512mb to 2048mb and I haven't received any app out of memory notifications since then so that seems to have cured it.

Thank you for your help.

@girish Thank you. The Red Hat documentation was roughly how I was thinking of it and in that case I should be fine with 1GB of swap (as I am not suspending the server, etc...) although 2GB might be better.

However, if i look at my apps they say, "Cloudron allocates 50% of this value as RAM and 50% as swap.". If that is a hard rule then that might explain why my apps seem to be restarting, even ones that don't get a huge amount of load (eg; low visit website), as after 8 x 256mb apps my swap space is fully allocated.

Now, I am running 17 apps at the moment and according to System Info/System Memory this is using 3GB of memory out of "RAM (3.85 GB) + Swap (984.99 MB)" which would seem to me to be a reasonable headroom unless the swap rule is hard at which point I have (assuming 256mb apps) over 2GB allocated to swap and under 1GB available.

So, is the swap rule hard? Because then it would seem to me to mean I need to have the same amount of swap as RAM. In my case 4GB.

Hopefully that is clear and thank you for your former reply.