@cpa ah, thanks. Another command for me to remember when troubleshooting apt...

@timconsidine said in Auto-update 7.3.4 - all apps down:

Phew, that was a scary platform update

Yes, 7.3 is pretty massive since it updates docker. So, it has to bring down everything and bring it up again.

@girish I didn't install anything, but I might have upgraded from 18 to 20 at some point as well as @Neluser did.

dpkg --configure -a resulted in dpkg: error: dpkg frontend lock is locked by another process, so I restarted the machine after all and updating worked fine.

Before that I killed the dpkg process and tried to run it, which resulted in that:

dpkg --configure -a Setting up grub-efi-amd64-signed (1.173.2~20.04.1+2.04-1ubuntu47.4) ... debconf: DbDriver "config": /var/cache/debconf/config.dat is locked by another process: Resource temporarily unavailable dpkg: error processing package grub-efi-amd64-signed (--configure): installed grub-efi-amd64-signed package post-installation script subprocess returned error exit status 1 dpkg: dependency problems prevent processing triggers for shim-signed: shim-signed depends on grub-efi-amd64-signed | grub-efi-arm64-signed; however: Package grub-efi-amd64-signed is not configured yet. Package grub-efi-arm64-signed is not installed. dpkg: error processing package shim-signed (--configure): dependency problems - leaving triggers unprocessed Errors were encountered while processing: grub-efi-amd64-signed shim-signed

Either way, solved not in the most elegant way, but solved 😄

@jdaviescoates said in How to cancel an update?:

@vladimir-d said in How to cancel an update?:

FTR, "Retry update task" and then "Restart App" have sorted the issue.

And then revert to previous backup?

@jdaviescoates It would be yes if there was a recent backup copy.

@eddowding said in Updating Cloudron to a stable version:

I was migrating servers when I noticed that I'm on 7.2.5, but the latest is 7.3.2.

When moving to the new server, you can install it as ./cloudron-setup --version 7.2.5 . 7.3 was out last week, just ironing out some regressions. We expect to start rolling it out next week.

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.

@robi said in Best way to update from Ubuntu 18.04 to 20.04?:

one can use the -y option for apt to 'assume yes' to all prompts.

this doesn't work with do-release-upgrade for whatever reason.

@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.

@JOduMonT it is only a daemon, but sometimes containers are recreated, images are managed and so forth which may use up a lot of server resources temporarily, especially if disk I/O is slow.

To give some reference here, we are talking about the code section from https://git.cloudron.io/cloudron/box/-/blob/master/src/apptask.js#L318 to https://git.cloudron.io/cloudron/box/-/blob/master/src/apptask.js#L340 so something is slow on your system in that area. Not sure how much tinkering you want to do for debugging, but you could stray in some console.log()s there to narrow down the issue. I can also help here, if you enable remote SSH support and send us a mail with your dashboard domain to support@cloudron.io

This happened to me to, and I had to do a full reboot to get the apps back up.

@Gary-Host Thanks. So to be clearer here about the update logs.

First, tail the log file /home/yellowtent/platformdata/logs/box.log Now, start the update in the UI You will see something like this in the logs: 2022-03-17T05:30:00.012Z box:tasks startTask - starting task 3970 with options {}. logs at /home/yellowtent/platformdata/logs/tasks/3970.log 2022-03-17T05:30:00.012Z box:shell startTask spawn: /usr/bin/sudo -S -E /home/yellowtent/box/src/scripts/starttask.sh 3970 /home/yellowtent/platformdata/logs/tasks/3970.log 0 400 Now, you can check the log file as listed above at /home/yellowtent/platformdata/logs/tasks/3970.log

That should give us info on why it's not updating.

@humptydumpty said in Backup Failed:
This is most likely to do with postgresql not having enough memory. Please go to Services and bump up the postgres memory.

@scooke I am now having an issue with my Onlyoffice app

Not responding
Fails to update
Logs show this every few minutes

Oct 21 17:30:59 => Initialize database Oct 21 17:30:59 psql: error: connection to server at "postgresql" (fd00:c107:d509::80), port 5432 failed: Connection refused Oct 21 17:30:59 Is the server running on that host and accepting TCP/IP connections? Oct 21 17:30:59 connection to server at "postgresql" (172.18.0.34), port 5432 failed: Connection refused Oct 21 17:30:59 Is the server running on that host and accepting TCP/IP connections?

Any thoughts ?

EDIT : I checked Services and saw Redis for this app had stopped. Restarted w/o problem.
But postgresql is shown in orange status and is trying to restart constantly.
Those logs show :

Oct 21 17:38:05 Debug mode. Sleeping Oct 21 17:38:20 Detected existing installation Oct 21 17:38:20 Resetting root password Oct 21 17:39:21 Detected existing installation Oct 21 17:39:21 Resetting root password Oct 21 17:40:23 Detected existing installation Oct 21 17:40:23 Resetting root password

EDIT(2) : rebooted box, postgresql restarted, seems to have cleared the issue.

@girish said in Cloudron update failing:

Indeed, the docker install logic was not cleaned up properly when we cleaned up other package installs. fixed now - https://git.cloudron.io/cloudron/box/-/commit/09d3d258b61ba338c0fadc88c0418d8bcc77f528 . Thanks for investigating!

Perhaps that fixes a similar bug, but just for clarity, note that I was using an old version Cloudron (6.1.2), and got stuck in this other loop that looks like it has already been removed from the script between version 6.2 and 6.3.

while ! dpkg --force-confold --configure -a; do log "Failed to fix packages. Retry" sleep 1 done

That “Failed to fix packages” is the message that appeared again and again in my infinite logs:

2022-01-13T17:05:53 ==> installer: Updating from 6.1.2 to 6.2.7 2022-01-13T17:05:53 ==> installer: updating docker 2022-01-13T17:05:58 ==> installer: Waiting for all dpkg tasks to finish... dpkg: dependency problems prevent configuration of linux-image-generic: linux-image-generic depends on linux-modules-extra-5.4.0-59-generic; however: Package linux-modules-extra-5.4.0-59-generic is not installed. dpkg: error processing package linux-image-generic (--configure): dependency problems - leaving unconfigured dpkg: dependency problems prevent configuration of linux-generic: linux-generic depends on linux-image-generic (= 5.4.0.59.62); however: Package linux-image-generic is not configured yet. dpkg: error processing package linux-generic (--configure): dependency problems - leaving unconfigured dpkg: dependency problems prevent configuration of linux-image-5.4.0-59-generic: linux-image-5.4.0-59-generic depends on linux-modules-5.4.0-59-generic; however: Package linux-modules-5.4.0-59-generic is not installed. dpkg: error processing package linux-image-5.4.0-59-generic (--configure): dependency problems - leaving unconfigured Errors were encountered while processing: linux-image-generic linux-generic linux-image-5.4.0-59-generic 2022-01-13T17:05:58 ==> installer: Failed to fix packages. Retry dpkg: dependency problems prevent configuration of linux-image-generic: … …

@girish Seemed like maybe Ubuntu was finishing some updates on boot which was blocking ssh from starting. I was pinging on 80 and 443 ports but ssh wasn't responding on 22 or 202 for a while.

@girish I found this when i clicked update:
61f3d999-30ce-405d-9639-1e1c26465759-image.png

Both my apps are running and are accessible.

I now tried stopping the Nextcloud instance and started it.
And it the app the 1 dead app is now 2 alive and 0 dead.
Now i could update normally.

Not sure what i missed in the first place but now works.

Thanks for the help 🙂

I have added a retry now for the startup tasks on db failures in 7.0.2

@girish @nebulon
I did not follow the upgrade tutorial for 16.04 → 18.04 → 20.04 entirely because I have some minor adjustments on the server that were blocking the upgrade. Also, there was a minor issue with docker in the past, where I edited the file /etc/apt/sources.list.d/docker.list so this whole problem was my fault 🙂

@privsec That worked, thanks!

@girish I would avoid deleting them, but instead migrate them to the deactivated directory.

@d19dotca Also, it's probably not clear from the UI because the UI is not optimized for the early upgraders. You can see https://git.cloudron.io/cloudron/box/-/blob/master/CHANGES for what exactly is the fix in the patch release.

Generally, I am wary of putting this information for general use (and even in docs) because many things can go wrong . So, please, if you care about the data, don't hesitate to contact us on support@ . We help regardless of the subscription plan.

@girish That did the trick. Thanks!

@imc67 said in Updating FreeScout failed:

@girish said in Updating FreeScout failed:

@imc67 there is a bug here . Can you apply this one liner and then set the memory limit https://git.cloudron.io/cloudron/box/-/commit/750f313c6a36d8d961892df4a41cb7c41faa1f1b ? You have systemctl restart box after you change that line in /home/yellowtent/box/src/apps.js.

Will try this in a few hours

@girish this solved the bug, thanks!

@drpaneas Just give that redis more memory. The "e1ca318a" is the app id. If you put in the search in the apps view, you will know which app's redis needs a bit more memory. It was reported earlier that pixelfed's redis needs more memory after the update. I guess this is because of update to Redis 5.

@johnbolt You should try a forced refresh (ctrl + shift + R on most browsers), to avoid cache issues

@girish ah so that’s because I was messing with dind for GitLab runner... whoops. Thanks for taking a look!

@imc67 I made https://git.cloudron.io/cloudron/box/-/issues/717 for keeping mail backups separately from the box backups.

@valkalon Cloudron support is still the best 😉