M
Hi guys,
I have this WordPress application crashed after attempting to restore to a backup. The restore task has been blocked due to a connection problem with the Contabo storage box.
I'm talking to Contabo support, but there seems to be some kind of problem with the storage box.
While they fix it, is there a way to unlock the recovery task and have the application start again?
Hi @nebulon,
I think @girish has already resolved the issue, because I can access my Cloudron Dashboard and all the applications are working correctly. In addition, it is already updated to version 8.0.3.
Anyway, I just enabled remote SSH support so you can take a look and know what could have happened.
Please keep me informed of what you find and when I can disable remote SSH support.
Yes @girish, this is the content of /home/yellowtent/platformdata/logs/tasks/14939.log:
2024-07-29T11:31:16.050Z box:taskworker Starting task 14939. Logs are at /home/yellowtent/platformdata/logs/tasks/14939.log
2024-07-29T11:31:16.255Z box:tasks update 14939: {"percent":1,"message":"Checking disk space"}
2024-07-29T11:31:16.257Z box:shell file execArgs: df ["-B1","--output=source,fstype,size,used,avail,pcent,target","/"]
2024-07-29T11:31:16.346Z box:tasks update 14939: {"percent":5,"message":"Downloading and verifying release"}
2024-07-29T11:31:16.348Z box:shell cleanupOldArtifacts exec: rm -rf /tmp/box-*
2024-07-29T11:31:20.263Z box:shell cleanupOldArtifacts: rm -rf /tmp/box-* errored Error: Command failed: rm -rf /tmp/box-*
rm: cannot remove '/tmp/box-2971389862/node_modules/ssh2/lib/protocol/crypto/build/config.gypi': Permission denied
at genericNodeError (node:internal/errors:984:15)
at wrappedFn (node:internal/errors:538:14)
at ChildProcess.exithandler (node:child_process:422:12)
at ChildProcess.emit (node:events:518:28)
at maybeClose (node:internal/child_process:1105:16)
at ChildProcess._handle.onexit (node:internal/child_process:305:5) {
code: 1,
killed: false,
signal: null,
cmd: 'rm -rf /tmp/box-*'
}
2024-07-29T11:31:20.266Z box:updater BoxError: cleanupOldArtifacts errored with code 1 message Command failed: rm -rf /tmp/box-*
rm: cannot remove '/tmp/box-2971389862/node_modules/ssh2/lib/protocol/crypto/build/config.gypi': Permission denied
at /home/yellowtent/box/src/shell.js:71:23
at ChildProcess.exithandler (node:child_process:430:5)
at ChildProcess.emit (node:events:518:28)
at maybeClose (node:internal/child_process:1105:16)
at ChildProcess._handle.onexit (node:internal/child_process:305:5)
2024-07-29T11:31:20.266Z box:updater downloadUrl: downloading https://releases.cloudron.io/versions.json to /home/yellowtent/platformdata/update/versions.json
2024-07-29T11:31:20.266Z box:shell downloadUrl execArgs: curl ["-s","--fail","https://releases.cloudron.io/versions.json","-o","/home/yellowtent/platformdata/update/versions.json"]
2024-07-29T11:31:21.766Z box:updater downloadUrl: done
2024-07-29T11:31:21.766Z box:updater downloadUrl: downloading https://releases.cloudron.io/versions.json.sig to /home/yellowtent/platformdata/update/versions.json.sig
2024-07-29T11:31:21.766Z box:shell downloadUrl execArgs: curl ["-s","--fail","https://releases.cloudron.io/versions.json.sig","-o","/home/yellowtent/platformdata/update/versions.json.sig"]
2024-07-29T11:31:22.568Z box:updater downloadUrl: done
2024-07-29T11:31:22.569Z box:updater gpgVerify: /usr/bin/gpg --status-fd 1 --no-default-keyring --keyring /home/yellowtent/box/src/releases.gpg --verify /home/yellowtent/platformdata/update/versions.json.sig /home/yellowtent/platformdata/update/versions.json
2024-07-29T11:31:22.569Z box:shell gpgVerify execArgs: /usr/bin/gpg ["--status-fd","1","--no-default-keyring","--keyring","/home/yellowtent/box/src/releases.gpg","--verify","/home/yellowtent/platformdata/update/versions.json.sig","/home/yellowtent/platformdata/update/versions.json"]
2024-07-29T11:31:22.671Z box:updater downloadUrl: downloading https://releases.cloudron.io/box-8d9043e590-8d9043e590-8.0.2.tar.gz to /home/yellowtent/platformdata/update/box.tar.gz
2024-07-29T11:31:22.672Z box:shell downloadUrl execArgs: curl ["-s","--fail","https://releases.cloudron.io/box-8d9043e590-8d9043e590-8.0.2.tar.gz","-o","/home/yellowtent/platformdata/update/box.tar.gz"]
Hi @girish,
These are the last lines from the last healthmonitor:
2024-07-29T11:30:53.167Z box:apphealthmonitor app health: 21 running / 5 stopped / 0 unresponsive
Finished with result: success
Main processes terminated with: code=exited/status=0
Service runtime: 6min 14.757s
CPU time consumed: 27.475s
box-task-14938 stopped
Service box-task-14938 finished with exit code 0
2024-07-29T11:30:53.283Z box:tasks startTask: 14938 completed with code 0
2024-07-29T11:30:53.285Z box:tasks setCompleted - 14938: {"error":{"message":"Task 14938 stopped","code":"stopped"}}
2024-07-29T11:30:53.285Z box:tasks update 14938: {"percent":100,"error":{"message":"Task 14938 stopped","code":"stopped"}}
2024-07-29T11:30:53.481Z box:locker Released : box_update
2024-07-29T11:30:53.482Z box:updater Update failed with error. { message: 'Task 14938 stopped', code: 'stopped' }
2024-07-29T11:30:53.483Z box:tasks startTask: 14938 done. error: { message: 'Task 14938 stopped', code: 'stopped' }
[object Object]
2024-07-29T11:31:03.507Z box:apphealthmonitor app health: 21 running / 5 stopped / 0 unresponsive
2024-07-29T11:31:10.737Z box:locker Acquired : box_update
2024-07-29T11:31:10.933Z box:tasks startTask - starting task 14939 with options {"timeout":72000000,"nice":15,"memoryLimit":1024}. logs at /home/yellowtent/platformdata/logs/tasks/14939.log
2024-07-29T11:31:10.934Z box:shell startTask /usr/bin/sudo -S -E /home/yellowtent/box/src/scripts/starttask.sh 14939 /home/yellowtent/platformdata/logs/tasks/14939.log 15 1024
Running as unit: box-task-14939.service
2024-07-29T11:31:14.236Z box:apphealthmonitor app health: 21 running / 5 stopped / 0 unresponsive
2024-07-29T11:31:22.563Z box:apphealthmonitor app health: 21 running / 5 stopped / 0 unresponsive
2024-07-29T11:31:30.906Z box:apphealthmonitor app health: 21 running / 5 stopped / 0 unresponsive
2024-07-29T11:31:36.621Z box:box Received SIGTERM. Shutting down.
2024-07-29T11:31:36.622Z box:platform uninitializing platform
2024-07-29T11:31:36.623Z box:shell startTask: /usr/bin/sudo -S -E /home/yellowtent/box/src/scripts/starttask.sh 14939 /home/yellowtent/platformdata/logs/tasks/14939.log 15 1024 errored BoxError: startTask exited with code null signal SIGTERM
at ChildProcess.<anonymous> (/home/yellowtent/box/src/shell.js:118:19)
at ChildProcess.emit (node:events:518:28)
at ChildProcess._handle.onexit (node:internal/child_process:294:12) {
reason: 'Shell Error',
details: {},
code: null,
signal: 'SIGTERM'
}
2024-07-29T11:31:36.623Z box:tasks startTask: 14939 completed with code null
2024-07-29T11:31:36.624Z box:platform onDeactivated: stopping post activation services
2024-07-29T11:31:36.625Z box:tasks stopAllTasks: stopping all tasks
2024-07-29T11:31:36.625Z box:shell stopTask /usr/bin/sudo -S /home/yellowtent/box/src/scripts/stoptask.sh all
2024-07-29T11:31:36.631Z box:tasks setCompleted - 14939: {"error":{"message":"Task 14939 crashed with code null","code":"crashed"}}
2024-07-29T11:31:36.631Z box:tasks update 14939: {"percent":100,"error":{"message":"Task 14939 crashed with code null","code":"crashed"}}
2024-07-29T11:31:36.634Z box:locker Released : box_update
2024-07-29T11:31:36.634Z box:updater Update failed with error. { message: 'Task 14939 crashed with code null', code: 'crashed' }
2024-07-29T11:31:36.634Z box:tasks startTask: 14939 done. error: { message: 'Task 14939 crashed with code null', code: 'crashed' }
All tasks stopped
Hi guys,
This morning I was updating my Cloudron instance to the latest version (8.0.2) and in the reboot process it got stuck and now I cannot access my Cloudron dashboard.
I have tried restarting the server, and it still won't boot. I have accessed via SSH and I see all the containers stopped, but they do not start.
Thank you very much in advance.
Hi @nebulon
No, the Baserow application has the standard configuration with which it is installed. Using it daily only stores about 100 rows in a table corresponding to the current month. It has been operating normally, until this anomaly occurred.
I have raised the memory available for the application to the maximum available, and it still does not work. The application marks running but the frontend cannot be accessed.
Furthermore, as you can see in the following screenshot, the memory barely exceeds normal consumption, but the CPU consumption slows down the operation of other applications on the server.
However, in recovery mode, with an allocation of 8 Gb of memory, the consumption of both memory and CPU is normal (you can see it in the hours before the screenshot, before the changes).
It has happened when upgrading from package version 1.19.2 to 1.20.0.
I have tested the application in Recovery Mode and running /app/pkg/start.sh manually and the application works, but when I exit Recovery Mode, the application stays in Not responding state.
Hi guys,
Since last weekend, my Baserow instance has started consuming excessive server resources (attached is a screenshot showing the CPU consumption spikes) and the frontend is not working. In fact, I noticed it wasn't working because the n8n workflows that use it were consistently failing.
Additionally, when reviewing the application logs, I found numerous warnings like the following:
Jul 22 18:44:59 Not configuring telemetry due to BASEROW_ENABLE_OTEL not being set.
Jul 22 18:45:00 [2024-07-22 16:45:00,098: INFO/MainProcess] Scheduler: Sending due task baserow.core.notifications.tasks.beat_send_instant_notifications_summary_by_email() (baserow.core.notifications.tasks.beat_send_instant_notifications_summary_by_email)
Jul 22 18:45:00 [2024-07-22 16:45:00,103: INFO/MainProcess] Task baserow.core.notifications.tasks.beat_send_instant_notifications_summary_by_email[1c6e7cb7-e7eb-4809-ae45-c46778e72594] received
Jul 22 18:45:00 [2024-07-22 16:45:00,304: INFO/MainProcess] Task baserow.core.notifications.tasks.singleton_send_instant_notifications_summary_by_email[bc948e50-4c8f-4229-96a2-4a79cc986bed] received
Jul 22 18:45:00 [2024-07-22 16:45:00,503: INFO/ForkPoolWorker-8] Task baserow.core.notifications.tasks.beat_send_instant_notifications_summary_by_email[1c6e7cb7-e7eb-4809-ae45-c46778e72594] succeeded in 0.3006958370006032s: None
Jul 22 18:45:00 [2024-07-22 16:45:00 +0000] [23] [WARNING] Worker with pid 226 was terminated due to signal 9
Jul 22 18:45:00 [2024-07-22 16:45:00,696: INFO/ForkPoolWorker-1] Task baserow.core.notifications.tasks.singleton_send_instant_notifications_summary_by_email[bc948e50-4c8f-4229-96a2-4a79cc986bed] succeeded in 0.2945839520007212s: None
Jul 22 18:45:00 [2024-07-22 16:45:00 +0000] [232] [INFO] Booting worker with pid: 232
Jul 22 18:45:02 [2024-07-22 16:45:01 +0000] [23] [CRITICAL] WORKER TIMEOUT (pid:227)
Jul 22 18:45:02 [2024-07-22 16:45:01 +0000] [23] [CRITICAL] WORKER TIMEOUT (pid:228)
Jul 22 18:45:02 [2024-07-22 16:45:02 +0000] [228] [INFO] Worker exiting (pid: 228)
Jul 22 18:45:02 Not configuring telemetry due to BASEROW_ENABLE_OTEL not being set.
Jul 22 18:45:02 Not configuring telemetry due to BASEROW_ENABLE_OTEL not being set.
Jul 22 18:45:02 [2024-07-22 16:45:02 +0000] [227] [INFO] Worker exiting (pid: 227)
Jul 22 18:45:03 [2024-07-22 16:45:03 +0000] [23] [WARNING] Worker with pid 227 was terminated due to signal 9
Jul 22 18:45:03 [2024-07-22 16:45:03 +0000] [233] [INFO] Booting worker with pid: 233
Jul 22 18:45:03 [2024-07-22 16:45:03 +0000] [23] [WARNING] Worker with pid 228 was terminated due to signal 9
Jul 22 18:45:03 [2024-07-22 16:45:03 +0000] [234] [INFO] Booting worker with pid: 234
Jul 22 18:45:07 => Healtheck error: Error: Timeout of 7000ms exceeded
Jul 22 18:45:07 172.18.0.1 - - [22/Jul/2024:16:45:07 +0000] "GET /_health HTTP/1.1" 499 0 "-" "Mozilla (CloudronHealth)"
Jul 22 18:45:17 => Healtheck error: Error: Timeout of 7000ms exceeded
Jul 22 18:45:17 172.18.0.1 - - [22/Jul/2024:16:45:17 +0000] "GET /_health HTTP/1.1" 499 0 "-" "Mozilla (CloudronHealth)"
Jul 22 18:45:22 [2024-07-22 16:45:22 +0000] [22] [CRITICAL] WORKER TIMEOUT (pid:229)
Jul 22 18:45:23 [2024-07-22 16:45:23 +0000] [22] [WARNING] Worker with pid 229 was terminated due to signal 6
Jul 22 18:45:23 [2024-07-22 16:45:23 +0000] [22] [CRITICAL] WORKER TIMEOUT (pid:230)
Jul 22 18:45:23 [2024-07-22 16:45:23 +0000] [22] [CRITICAL] WORKER TIMEOUT (pid:231)
Jul 22 18:45:23 [2024-07-22 16:45:23 +0000] [235] [INFO] Booting worker with pid: 235
Jul 22 18:45:24 [2024-07-22 16:45:24 +0000] [22] [WARNING] Worker with pid 230 was terminated due to signal 6
Jul 22 18:45:24 [2024-07-22 16:45:24 +0000] [236] [INFO] Booting worker with pid: 236
Jul 22 18:45:24 [2024-07-22 16:45:24 +0000] [22] [WARNING] Worker with pid 231 was terminated due to signal 9
Jul 22 18:45:24 [2024-07-22 16:45:24 +0000] [237] [INFO] Booting worker with pid: 237
Jul 22 18:45:25 172.18.0.1 - - [22/Jul/2024:16:45:25 +0000] "GET /_health HTTP/1.1" 200 162736 "-" "Mozilla (CloudronHealth)"
Jul 22 18:45:31 Not configuring telemetry due to BASEROW_ENABLE_OTEL not being set.
Jul 22 18:45:31 [2024-07-22 16:45:30 +0000] [23] [CRITICAL] WORKER TIMEOUT (pid:232)
Jul 22 18:45:31 [2024-07-22 16:45:30 +0000] [232] [INFO] Worker exiting (pid: 232)
Jul 22 18:45:32 [2024-07-22 16:45:32 +0000] [23] [WARNING] Worker with pid 232 was terminated due to signal 9
Jul 22 18:45:32 [2024-07-22 16:45:32 +0000] [238] [INFO] Booting worker with pid: 238
Jul 22 18:45:33 [2024-07-22 16:45:33 +0000] [23] [CRITICAL] WORKER TIMEOUT (pid:233)
Jul 22 18:45:33 [2024-07-22 16:45:33 +0000] [23] [CRITICAL] WORKER TIMEOUT (pid:234)
Jul 22 18:45:33 Not configuring telemetry due to BASEROW_ENABLE_OTEL not being set.
Jul 22 18:45:33 [2024-07-22 16:45:33 +0000] [234] [INFO] Worker exiting (pid: 234)
Jul 22 18:45:33 [2024-07-22 16:45:33 +0000] [233] [INFO] Worker exiting (pid: 233)
Jul 22 18:45:34 Not configuring telemetry due to BASEROW_ENABLE_OTEL not being set.
Jul 22 18:45:35 [2024-07-22 16:45:35 +0000] [23] [WARNING] Worker with pid 234 was terminated due to signal 9
Jul 22 18:45:35 [2024-07-22 16:45:35 +0000] [23] [WARNING] Worker with pid 233 was terminated due to signal 9
Jul 22 18:45:35 [2024-07-22 16:45:35 +0000] [23] [DEBUG] 2 workers
Jul 22 18:45:35 [2024-07-22 16:45:35 +0000] [240] [INFO] Booting worker with pid: 240
Jul 22 18:45:35 [2024-07-22 16:45:35 +0000] [23] [DEBUG] 3 workers
Jul 22 18:45:35 172.18.0.1 - - [22/Jul/2024:16:45:35 +0000] "GET /_health HTTP/1.1" 200 162743 "-" "Mozilla (CloudronHealth)"
I have tried both restoring a backup from previous days and updating to the latest version, and the time for both processes far exceeds 30 minutes for each operation, which is not normal.
Any suggestions or indications of what might be happening?
Hi guys,
In the n8n community node repository there are some nodes (n8n-nodes-browser, n8n-nodes-puppeteer-extended) based on Puppeteer, but when trying to extract data from any url using n8n, the following error appears in the application log:
Jul 27 20:03:41 Service path not specified, so defaulting to ipc.config.socketRoot + ipc.config.appspace + id
Jul 27 20:03:41 Already Connected to puppeteer - So executing success without connection
Jul 27 20:03:41 dispatching event to puppeteer /tmp/app.puppeteer : launch , {
Jul 27 20:03:41 globalOptions: { device: 'iPad Pro 11 landscape' },
Jul 27 20:03:41 executionId: '9424'
Jul 27 20:03:41 }
Jul 27 20:03:41 received event of : launch {
Jul 27 20:03:41 globalOptions: { device: 'iPad Pro 11 landscape' },
Jul 27 20:03:41 executionId: '9424'
Jul 27 20:03:41 }
Jul 27 20:03:41 Error: Could not find Chromium (rev. 1095492). This can occur if either
Jul 27 20:03:41 1. you did not perform an installation before running the script (e.g. `npm install`) or
Jul 27 20:03:41 2. your cache path is incorrectly configured (which is: /home/cloudron/.cache/puppeteer).
Jul 27 20:03:41 For (2), check out our guide on configuring puppeteer at https://pptr.dev/guides/configuration.
Jul 27 20:03:41 at ChromeLauncher.resolveExecutablePath (/app/data/user/.n8n/nodes/node_modules/puppeteer-core/src/node/ProductLauncher.ts:134:17)
Jul 27 20:03:41 at ChromeLauncher.executablePath (/app/data/user/.n8n/nodes/node_modules/puppeteer-core/src/node/ChromeLauncher.ts:251:19)
Jul 27 20:03:41 at ChromeLauncher.launch (/app/data/user/.n8n/nodes/node_modules/puppeteer-core/src/node/ChromeLauncher.ts:103:31)
Jul 27 20:03:41 at PuppeteerExtra.launch (/app/data/user/.n8n/nodes/node_modules/puppeteer-extra/src/index.ts:169:21)
Jul 27 20:03:41 at default_1 (/app/data/user/.n8n/nodes/node_modules/n8n-nodes-puppeteer-extended/nodes/Puppeteer/puppeteer/start.ts:28:18)
Jul 27 20:03:41 at /app/data/user/.n8n/nodes/node_modules/n8n-nodes-puppeteer-extended/nodes/Puppeteer/puppeteer/index.ts:23:16
Jul 27 20:03:41 dispatching event to socket : launch false
Jul 27 20:03:41 ## received events ##
Jul 27 20:03:41 detected event launch false
Jul 27 20:03:41 Service path not specified, so defaulting to ipc.config.socketRoot + ipc.config.appspace + id
Jul 27 20:03:41 Already Connected to puppeteer - So executing success without connection
Jul 27 20:03:41 dispatching event to puppeteer /tmp/app.puppeteer : check , {
Jul 27 20:03:41 executionId: '9424',
Jul 27 20:03:41 apiKey: 'n8n_api_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx',
Jul 27 20:03:41 baseUrl: 'https://n8n.xxxxxxxxxx.xxx/api/v1'
Jul 27 20:03:41 }
Jul 27 20:03:41 received event of : check {
Jul 27 20:03:41 executionId: '9424',
Jul 27 20:03:41 apiKey: 'n8n_api_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx',
Jul 27 20:03:41 baseUrl: 'https://n8n.xxxxxxxxxx.xxx/api/v1'
Jul 27 20:03:41 }
Jul 27 20:03:41 dispatching event to socket : check true
Jul 27 20:03:41 ## received events ##
Jul 27 20:03:41 detected event check true
Is there a possibility to include it in the application package? 
Hey @alwynispat
Maybe you should use the SSH node instead of the Execute Command node. From what I understand the Whois package is installed on the server, so to run it you will have to call it via ssh command.
The Execute Command node executes commands inside the cloudron n8n container, which by default will run in the /app/code path of your n8n container.
That is the reason why it does not find the Whois package when running the Execute Command node.
This error occurs when something has modified the .htaccess file.
Normally, re-saving the permalink settings will fix it. It happens many times when you perform a WordPress site migration.
@marcusquinn another faster option is to change in the wp_usermeta table of the database the initial meta_value of the meta_key wp_capabilities to a:1:{s:13:"administrator";b:1;}
With that, the user newly created by LDAP has administrator permissions. Just delete or modify the user_login admin user in the wp_users table to make it less vulnerable.
Of course, sharing the same LDAP user and password in multiple applications is not a safe practice either 
And finally, you can also create a small n8n workflow in which passing the appID of the WordPress installation in Cloudron, does all the work for you... 
Hi @simong
Any binary file found in /app/data/ can be read or written by n8n in Cloudron
Hi @jquintana
Do all plugins and themes come from "trusted" developers or sites?
With that, the installation should be secured.
Hi @shrey
I have tried to reproduce the CORS error you mention, but in all my attempts, everything works correctly.
I have created a workflow from the example you left in the n8n support forum on an instance of n8n running on Cloudron.
When calling the webhook url from the browser itself, the workflow starts without problems.
And when I make an HTTP Request from another n8n instance (with a different domain) on a different server running Cloudron, the response is the same.
@shrey Can you share an example of the workflow you are trying to call through a webhook to try to reproduce the error?
I have several instances of n8n running on Cloudron and have never had any problems running workflows using the Webhooks trigger node.
@jeau @jdaviescoates The mysql host IP changes every time the server is restarted.
If you access the SSH console of your server and enter the following command, you will see the current IP.
docker inspect mysql | grep IPAddress
root@xxxxxxxxx:~# docker inspect mysql | grep IPAddress
"SecondaryIPAddresses": null,
"IPAddress": "",
"IPAddress": "172.18.0.18",
If you restart and repeat the process, you will see how the IP has changed (at least in its last two digits).
This host value is important when you make external connections to the WordPress database through an SSH tunnel.
@LoudLemur If all the platforms to which you want to upload the video have an API with an endpoint that allows the file upload, you can use n8n (available from Cloudron) to automate this task.
With YouTube I know it is possible by making an HTTP Request to their API passing the file and video data.