Cloudron Forum

@girish 🤔 it seems the most recent update worked....while i did change some email settings, the only other action I took was manually bumping along the updates several versions. So there must have been some sort of inconsistent state that came up.

It seems all is well with the world and no way to track down what happened.

Thanks for the help, all.

@jdaviescoates Phew, my thoughts and prayers worked!

@jdaviescoates you could set up a cron that gets usage info, and prints out a webpage you can monitor with Kuma for a keyword. When a threshold is met, you add/remove the keyword and fire off an alert via TG.

Similar for monitoring something with change detection app or n8n workflow.

The issue here was that unbound was not working. Because of that, all the docker image updates are failing like so:

2022-12-06T03:38:02.801Z box:shell startGraphite exec: docker run --restart=always -d --name="graphite" --hostname graphite --net cloudron --net-alias graphite --log-driver syslog --log-opt syslog-address=udp://127.0.0.1:2514 --log-opt syslog-format=rfc5424 --log-opt tag=graphite -m 429916160 --memory-swap 536870912 --dns 172.18.0.1 --dns-search=. -p 127.0.0.1:2003:2003 -v "/home/yellowtent/platformdata/graphite:/var/lib/graphite" --label isCloudronManaged=true --read-only -v /tmp -v /run "cloudron/graphite:3.2.0@sha256:182e5cae69fbddc703cb9f91be909452065c7ae159e9836cc88317c7a00f0e62" Box GET /api/v1/appstore/apps?repository=core 424 Failed Dependency getaddrinfo EAI_AGAIN api.cloudron.io 10.852 ms - 89 2022-12-06T03:38:03.581Z box:shell startGraphite (stdout): null 2022-12-06T03:38:03.581Z box:shell startGraphite (stderr): Unable to find image 'cloudron/graphite:3.2.0@sha256:182e5cae69fbddc703cb9f91be909452065c7ae159e9836cc88317c7a00f0e62' locally docker: Error response from daemon: Get "https://registry-1.docker.io/v2/": dial tcp: lookup registry-1.docker.io on 127.0.0.1:53: server misbehaving. See 'docker run --help'.

It was hard to figure why unbound is not working, all queries fail with ESERVFAIL (VM, Hyper-V, router, many things here). It's some networking related issue hard to diagnose without getting a full hand on the setup. The workaround was to add a file called /etc/unbound/unbound.conf.d/forward-everything.conf with the following:

forward-zone: name: "." forward-addr: 1.1.1.1 forward-addr: 8.8.8.8

Then, systemctl restart unbound . After that, host cloudron.io 127.0.0.1 should work.

Finally, systemctl restart box will then bring up all the containers again.

See https://forum.cloudron.io/topic/8101/fix-for-kernel-bug-in-ubuntu-20-04-causing-various-issues for a solution.

Cloudron won’t skip an update and will install them per your defined schedule. I have a shut down Wordpress app but temporarily keeping it for archiving purposes and I had to update it several times to get to the latest. I know from experience that WP won’t play nice if you skip updates (especially major version ones).

@nebulon thanks! I'm not getting my hopes up too far, but hopefully this will somehow also resolve all the issues that loads of the official plugins have when trying to install them on Cloudron...

@girish this has been reworked and will not explicitly state if there is no new update available, while hiding the disabled update button again.

Or if the app supports import/export of it's own, then install the latest version of the app and import the previous one into it.

Also, the reason for nextcloud update is that it has some slightly tricky optimization to change ownership of files carefully. It also changes the default data directory of newer nextcloud installations.

@jdaviescoates Oh, it was made available to all only yesterday. So, probably takes a couple more days to actually auto-update.

As a hack, change the update schedule for every hour 😄

Related note: would be nice if we could display "the app is xx updates behind". We don't have an appstore API for this though.

@girish I checked, and there is nothing set there, so it's what the ISP is providing.

@fbartels thanks for that. I was getting caught up in a missionary fervor!

Ubuntu notice - https://ubuntu.com/security/notices/USN-4891-1

This is both for retry when, for example the backup done prior to the update, fails temporarily, as well as if apps and platform gets updates, they lock each other so retries in not so busy times are an effective workaround.

@girish Many thanks Girish. It must have been a space problem indeed. Looking at the log, the processed froze while downloading the last big part of the image (~570MB). I tried to duplicate the app, which worked fine but and the process also froze when trying to update it (also while downloading that part the image).

Anyway, I had a about 3GB of free space which I though would be enough to update Wekan but after doing some cleaning up on the server (like deleting old apps I wasn't using), I went to about 7GB of free space and the update started working again.

@girish said in Automatic Updates - updated Cloudron but none of the apps:

box update only happens like once a month, so we have decided to ignore this

Ahh, okay. Yeah I figured it was a rare occurrence so no biggie there. This situation though is what lead me to the feature request on bulk-updating the app updates on demand.

@girish this was a different Cloudron than the DNS MX issue which is still persisting ;-/

@ruihildt Updates to packages are rolled out slowly. So if a user tries to check for an update manually (i.e they click for 'check for updates') and they are not part of the rollout, they get shown that message. Generally, it is safe to update anyway but we are just being careful here.