Cloudron Forum

Thanks!!

@inibudi , it is; but I've optimized it down to a single crontab entry:

crontab -l
48 2 * * * /bin/sh -c '[ -f /var/run/reboot-required ] && sudo shutdown -r now'

I do have a subscription. Just yesterday I've figured out the problem is with HTTP 2 protocol that is failing on the hand-over; disabling it on the proxy and leaving with HTTP 1.1 works just fine, as the protocol do the fallback from H2 to WebSocket over HTTP 1.1, which works just fine.

you should have mentioned earlier

@james I wish I was aware that it is the problem!

The whole cloudron is behind a haproxy that does TCP level proxy. From my understanding it should not affect, as it's one level below the HTTP(S) and WebSocket is above HTTPS.

And the console doesn't seem to work for all apps terminals.

Any ideas how to narrow down the root cause?

@nebulon thank you. And yes - I understand why the work-around required. If you don't mind sharing the source code to read the logic exactly?

I've been wondering on the best way to achieve that, but never seen any good practical approach - would love to see how you are approaching that, without a container shutdown, if you don't mind sharing of course.

If that's too complicated - never mind and please, feel free to close the issue - the question now is purely to satisfy my curiosity.

Thank you, that fixed the issue.
There been no logs in the container.

Any ideas what is the nature of the sqlite container for uptime kuma? I've been under impression that sqlite requires no server side...

Hello, @james . Thanks!

For anyone wondering of the same - the best way is the following commands - from any other computer, then the server.

npx cloudron login my.precious.com
npx cloudron list
npx cloudron exec --app $id--tty

(no need to install anything globally)

Nothing at the box.log, I'm getting the following error from the cli:

npx cloudron exec --app e085a31f-7f7f-40ff-ae95-056766d2781d --tty
Could not upgrade connection to tcp. http status: 502

And here is the nginx log entries:

IP - - [21/Jan/2026:14:18:03 +0000] "GET /api/v1/apps/e085a31f-7f7f-40ff-ae95-056766d2781d HTTP/2.0" 200 7965 "-" "-"
IP - - [21/Jan/2026:14:18:03 +0000] "POST /api/v1/apps/e085a31f-7f7f-40ff-ae95-056766d2781d/exec HTTP/2.0" 200 78 "-" "-"

The Cloudron is behind a proxy, but I can't see any WebSocket related restrictions.

@nebulon there seems to be none of the dead ones:

ubuntu@cloudron:~$ sudo docker ps -a | grep sqlite | wc -l
1
ubuntu@cloudron:~$ sudo docker ps -a | grep sqlite
bbb52ef9e686   cloudron/louislam.uptimekuma.app:202511081423470000       "sqlite3 /app/data/d…"   2 weeks ago   Created                                                                                                                                                                sqlite-be0be218-57bf-427b-abb6-b7660943eaf6

There are not that much non-running containers - only 2 nextcloud workers with exit(0) and another service, that I have stopped explicitely.

@nebulon will do, thanks.

Could you please, tell me - what cloudron exec does? Never used it - only using WebUI and ssh command lines on the server, in those rare cases, when got to check something.

and that is happening not only for NextCloud actually, I just didn't notice!

@nebulon I do:

terminal-c5ikyfn6.js:6307 WebSocket connection to 'wss://my.server.com/api/v1/apps/e075a2fe-7f7f-40ff-ae12-056766d2780d/exec/d7f60f4a9d5d72e7ced6aaf3d0f035fbe98c397f37690fe99ddcba72b0539d97/startws?tty=true&rows=25&columns=183&access_token=a8uNp2OOgZpy_00xcyYa3gKGGAb8SQGO0B6-Tydok3k' failed: 
connect @ terminal-c5ikyfn6.js:6307
terminal-c5ikyfn6.js:6322 Socket error. Reconnecting... Event {isTrusted: true, type: 'error', target: WebSocket, currentTarget: WebSocket, eventPhase: 2, …}
terminal-c5ikyfn6.js:6317 Socket closed. Reconnecting...

Yep - it does.
Stop & start didn't help, unfortunately.

Hey, James. Quite a while ago. Don't you want to figure out the root cause?
I can and certainly will reboot the server one day.

@james said in Backup is failing for UpTime Kuma on 9.0.15:

How many hosts do you monitor with Uptime Kuma?

not much - like 20 max; UpTime Kuma on itself works just fine.

@james said in Backup is failing for UpTime Kuma on 9.0.15:

Or do you mean this setting is getting overwritten again and again?

yeah - I always have my settings setup in a way, that I would be getting an e-mail for the threads I'm participating and from time to time I'm finding myself not getting those updates - going to check the settings and they are again in 'Notification only'.

It's sporadic, but I'm quite sure I didn't change them manually (too lazy / busy for that - I don't even remember where they are in the profile).

Just in case - the forum software keeps changing my e-mail notification settings. I'm returning to e-mail notifications for the topic I've created for a second or third time now and it keeps reseting to notifications only.

Only with NextCloud and it seems like was working fine...

Hello @james , I believe I did

After update to v9 of Cloudron from latest v8, UpTime Kuma can't be backed up

It's UpTime Kuma

I'm trying to connect to NextCloud console on Cloudron 9.0.15, but that is all I'm getting:

Resources are fine, log messages shows that container exists and doing well.

sudo docker exec -it ebc4eb53c325 /bin/bash

works just fine.

After update to v9 of Cloudron from latest v8, UpTime Kuma can't be backed up - failing the whole backup process - so I had to exclude it.

I don't mind not backing up, but I afraid it might be a sign of something bigger.

Here are the logs:

Jan 07 12:22:43 box:tasks updating task 13869 with: {"percent":46.45454545454546,"message":"Backing up check.domain.com (5/8). Waiting for lock"}
Jan 07 12:22:43 box:locks write: current locks: {"full_backup_task_33af5ff8-0a0d-4250-9c1d-15bf8e6529fe":null,"app_backup_be0be218-57bf-427b-abb6-b7660943eaf6":"13869"}
Jan 07 12:22:43 box:locks acquire: app_backup_be0be218-57bf-427b-abb6-b7660943eaf6
Jan 07 12:22:43 box:tasks updating task 13869 with: {"percent":46.45454545454546,"message":"Snapshotting app check.domain.com"}
Jan 07 12:22:43 box:services backupAddons
Jan 07 12:22:43 box:services backupAddons: backing up ["localstorage"]
Jan 07 12:22:43 box:services Backing up sqlite
Jan 07 12:22:43 box:shell services: /bin/bash -c docker run --rm --name=sqlite-be0be218-57bf-427b-abb6-b7660943eaf6 --net cloudron --log-driver=none -v /home/yellowtent/appsdata/be0be218-57bf-427b-abb6-b7660943eaf6/data:/app/data --label isCloudronManaged=true --read-only -v /tmp -v /run cloudron/louislam.uptimekuma.app:202511081423470000 sqlite3 /app/data/data/kuma.db ".dump" > /home/yellowtent/appsdata/be0be218-57bf-427b-abb6-b7660943eaf6/kuma.sqlite
Jan 07 12:22:43 box:shell services: /bin/bash -c docker run --rm --name=sqlite-be0be218-57bf-427b-abb6-b7660943eaf6 --net cloudron --log-driver=none -v /home/yellowtent/appsdata/be0be218-57bf-427b-abb6-b7660943eaf6/data:/app/data --label isCloudronManaged=true --read-only -v /tmp -v /run cloudron/louislam.uptimekuma.app:202511081423470000 sqlite3 /app/data/data/kuma.db ".dump" > /home/yellowtent/appsdata/be0be218-57bf-427b-abb6-b7660943eaf6/kuma.sqlite errored BoxError: /bin/bash exited with code 125 signal null
Jan 07 12:22:43 at ChildProcess.<anonymous> (/home/yellowtent/box/src/shell.js:82:23)
Jan 07 12:22:43 at ChildProcess.emit (node:events:519:28)
Jan 07 12:22:43 at maybeClose (node:internal/child_process:1101:16)
Jan 07 12:22:43 at ChildProcess._handle.onexit (node:internal/child_process:304:5) {
Jan 07 12:22:43 reason: 'Shell Error',
Jan 07 12:22:43 details: {},
Jan 07 12:22:43 stdout: '',
Jan 07 12:22:43 stdoutLineCount: 0,
Jan 07 12:22:43 stderr: 'docker: Error response from daemon: Conflict. The container name "/sqlite-be0be218-57bf-427b-abb6-b7660943eaf6" is already in use by container "bbb52ef9e6869b43778e5bd796d52dcece50162fd45658877200006219c3f259". You have to remove (or rename) that container to be able to reuse that name.\n' +
Jan 07 12:22:43 '\n' +
Jan 07 12:22:43 "Run 'docker run --help' for more information\n",
Jan 07 12:22:43 stderrLineCount: 3,
Jan 07 12:22:43 code: 125,
Jan 07 12:22:43 signal: null,
Jan 07 12:22:43 timedOut: false,
Jan 07 12:22:43 terminated: false
Jan 07 12:22:43 }
Jan 07 12:22:43 box:backuptask fullBackup: app check.domain.com backup finished. Took 0.021 seconds
Jan 07 12:22:43 box:locks write: current locks: {"full_backup_task_33af5ff8-0a0d-4250-9c1d-15bf8e6529fe":null}
Jan 07 12:22:43 box:locks release: app_backup_be0be218-57bf-427b-abb6-b7660943eaf6
Jan 07 12:22:43 box:tasks setCompleted - 13869: {"result":null,"error":{"message":"/bin/bash exited with code 125 signal null","reason":"Shell Error"},"percent":100}
Jan 07 12:22:43 box:tasks updating task 13869 with: {"completed":true,"result":null,"error":{"message":"/bin/bash exited with code 125 signal null","reason":"Shell Error"},"percent":100}
Jan 07 12:22:43 box:taskworker Task took 9.642 seconds
Jan 07 12:22:43 BoxError: /bin/bash exited with code 125 signal null
Jan 07 12:22:43 at ChildProcess.<anonymous> (/home/yellowtent/box/src/shell.js:82:23)
Jan 07 12:22:43 at ChildProcess.emit (node:events:519:28)
Jan 07 12:22:43 at maybeClose (node:internal/child_process:1101:16)
Jan 07 12:22:43 at ChildProcess._handle.onexit (node:internal/child_process:304:5)
Jan 07 12:22:43 Exiting with code 0