@nebulon I could enable ssh on the cloudrons in question and you could take a look, should I do that and write down some timestamps of the restarts? maybe you see something that I don't, email is not my strongsuit and there is a lot happening that I don't know 😉
@jlx89 I can see that feature being useful to have a proper overview of archived apps, rather than trying to workaround with existing paradigms. Stopping the app would keep the allocated resources like domain and ports bound to this instance as well. Depending on the use-case this may be good or bad. Generally I think you can achieve that already by keeping a copy of the apps last backup around on some other storage (this is quite easy with tarball backend)
Maybe we add some UI for this later, but this is not on our feature list for next release at least, so we can explore this first a bit further here, so any input is welcome.
@necrevistonnezr you can delete those files safely, of course you will lose all logs history, but if you don't have any immediate issue on your server besides log size, you can just remove them via ssh.
@girish I'm not sure if that makes complete sense to me yet, but as always I appreciate the detailed explanation.
I can understand that Cloudron is checking to make sure an app hostname can be resolved, but I'd think it just needs to do a DNS lookup to make sure it can resolve the hostname of the app, then proceed forward. I don't quite understand why it care about the name server side of things. As long as the app hostnames are resolvable, shouldn't that be sufficient?
In my case, the IP isn't changing, nothing is changing other than I want to use DigitalOcean DNS whereas I currently use a Wildcard DNS backend. Everything is already working as-is and has been for quite some time. I should be able to link Cloudron up to DigitalOcean's DNS API to generate all the required DNS entries in the new service provider before needing to change name servers.
If Cloudron's main focus is to make sure the app "can be accessed via the browser immediately", then it should just need to care if the hostname is currently resolvable, right?
The best practice would be to switch name servers last when switching DNS providers for a domain, and the way Cloudron seems to currently work I cannot have Cloudron setup the new DNS service ahead of time before switching the name servers since it requires the name servers set first, which seems a bit backwards to me. Part of the beauty of that function is that Cloudron sets the DNS entries is automation, but this current behaviour is now requiring manual steps which seem unnecessary.
I guess the process just seems "off" to me, or rather backwards from how I'd think it should operate to achieve best practices and convenience to users.
@girish If something happened in the past (like the cifs mount being down) that caused the previous backups not to be deleted would there be any log on the system I could look through to see an error?
In the mean time I will manually delete everything not listed in the log output above and then report back in 7 days.
@jdaviescoates, I have been having problems with the backups being deleted automatically for 3+ months and have been trying different things and have several times moved the backups out of the directory they were in, deleted everything from cloudron, unconfigured the backups, and reconfigured them again, ran them for more than 7 days, confirmed that they still were not being cleaned up properly, rinse and repeat with different configurations and options.
I opened this support thread after reaching what I believe to be a correct/supported configuration that started fresh that has been running for longer than 12 days (with a 7 day retention period) with no prior backups in the directory and confirming that the issue is still occurring.
Looking at this again, I don't think there is actually a web app nor any server components. It's all just desktop and mobile apps that communicate directly with each other, so I don't think it could really be an app on Cloudron.
Saying that, "JAMS - Jami Account Management Server" (as mentioned by @stoccafisso ) does sound very much like it's a server thing! So I guess that could be a Cloudron app?
@rmdes on the managed app, you cannot update WP. It will behave similar to what you faced i.e it will ask for credentials. This is because WP figures that it cannot write to the code directory and falls back to uploading code via FTP (a behavior I really dislike but I don't think this can be disabled).
@girish that's a great idea! I like the proxyAuth because it limits the number of credentials one needs to access their apps, but you're right in the way that it ends being less secure since you might end up using it in other places that might not be as secure.