SQL error
-
Tried updating cloudron and we got this error
SQL is not runinng:(HTTP code 500) server error - Cannot restart container mysql: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error mounting "/home/yellowtent/platformdata/mysql" to rootfs at "/var/lib/mysql": mount /home/yellowtent/platformdata/mysql:/var/lib/mysql (via /proc/self/fd/6), flags: 0x5000: not a directory: unknown: Are you trying to mount a directory onto a file (or vice-versa)? Check if the specified host path exists and is the expected type
Our version:
v7.7.2 (Ubuntu 20.04.5 LTS)
VendorLinode
ProductCompute Instance
CPU16 Core "AMD EPYC 7542 32-Core Processor"
Memory33.66 GB RAM & 4.29 GB Swap
storage 600+
storage used: 400+
Kernel: We tried 5.4, 5.10 and 5.15 -
@james sorry of the late response I tried it, and it shows these data
root@CloudronMain:~# cloudron-support --troubleshoot
[OK] node version is correct
[OK] docker is running
[OK] MySQL is running
[OK] nginx is running
[OK] box is running
[OK] unbound is running
[OK] Dashboard is reachable via domain name
[OK] Domain elevatecalls.io is valid and has not expired
root@CloudronMain:~# -
Usually, that error happens when docker became corrupt (for example, server ran out of disk space). Is that a possibility in your case? This is quite an old version of Cloudron. The recent versions of cloudron-support have --recreate-docker but I don't think it's there ins Cloudron 7 . If you write to support@cloudron.io , I can look into it.
-
Usually, that error happens when docker became corrupt (for example, server ran out of disk space). Is that a possibility in your case? This is quite an old version of Cloudron. The recent versions of cloudron-support have --recreate-docker but I don't think it's there ins Cloudron 7 . If you write to support@cloudron.io , I can look into it.
-
I’d like to inform everyone that our current backup takes approximately 3 hours and 45 minutes to complete.
In the event that the server goes down, the full restoration process could take 8–9 hours or possibly longer, depending on the situation.
With this in mind, I would like to ask for your recommendation on how we should proceed. Would it be better to schedule this activity over the weekend to minimize disruption to our employees and clients in case a restore is required?
If we are confident that this will not cause any issues or downtime, we can proceed today.
Please advise on the best course of action.