Cloudron makes it easy to run web apps like WordPress, Nextcloud, GitLab on your server. Find out more or install now.


  • Categories
  • Recent
  • Tags
  • Popular
  • Bookmarks
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse

Cloudron Forum

Apps | Demo | Docs | Install

Unrecoverable NodeBB error after NPM install

Scheduled Pinned Locked Moved NodeBB
6 Posts 3 Posters 41 Views
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • T Offline
    T Offline
    True
    wrote last edited by
    #1

    Dear Support, I got this error message after rebooting the app. Recovering the unsuccessful from stable backup

    • It's not possible to reboot from dashboard or put it into recovery mode
    • Terminal for the app doesn't open (file explorer does)
    • Uninstalling the app is not possible. **Error message: Cloudron Error
    • getaddrinfo EAI_AGAIN api.cloudron.io**
      1ac5293e-780e-4cf8-aac3-aa4081109b1e-image.png
    • The error seems to affect the Cloudron app store as well. Nothing loads...

    See repair options below.
    4f7ef1dc-876e-4ee2-bf4f-c64353cde2a3-image.png

    This happened after

    • I tried to install some NPM packages over the cloudron terminal for NodeBB.
    • The install didn't go through (write error)
    • I created a temp folder to install NPM and force my way through.
    mkdir /tmp/my_modules
    cd /tmp/my_modules
    chmod -R 777 /tmp/my_modules
    npm install nodebb-plugin-calendar@latest
    

    Install stalled and probably didn't go through. The plugins list in NodeBB ACP didn't load properly first. After rebooting nodeBB, it must have broke the container 😞 Any suggestions on how to fix this?

    1 Reply Last reply
    0
  • nebulonN Offline
    nebulonN Offline
    nebulon Staff
    wrote last edited by
    #2

    Are you able to run host api.cloudron.io via ssh on your server to verify that the DNS resolving works correctly?

    1 Reply Last reply
    0
  • girishG Offline
    girishG Offline
    girish Staff
    wrote last edited by
    #3

    I would check if unbound is working correctly - https://docs.cloudron.io/troubleshooting/#unbound

    1 Reply Last reply
    0
  • T Offline
    T Offline
    True
    wrote last edited by
    #4

    SOLVED: Thank you for the suggestions. The api.cloudron.io might have been down temporarily.

    • I ran host api.cloudron.io and it resolved to an IP address
    • I found it strange, so I opened the app store and indeed everything was loading.
    • Then I tried the recovery again to a stable version. It connected to the API to pull the image.
    • After recovery the app was non responsive. It asked me to follow https://docs.cloudron.io/troubleshooting/#unresponsive-app
    • I went into recovery mode, but couldn't find the correct script like "start.sh" to restart it.
    • Without doing anything I disabled recovery mode and restarted the app. Opened to logs and it showed, it started reponding.🤣
    • It's working fine now.

    I am bit surprised and concerned that the API connection has such a strong impact on recovery. If the API is not reachable then the correct image won't re-download. Bringing recovery to a stall. I am testing currently, but in production this can be a blocker. Is there a way to preload the image on Cloudron instance in case of emergency?

    1 Reply Last reply
    0
  • girishG Offline
    girishG Offline
    girish Staff
    wrote last edited by
    #5

    The root cause here is not api.cloudron.io as such but that DNS was not working in general. If DNS is not working, many things fail - for example, download docker images, download app manifest information etc. The icon download is one of the first things that happen in an app's lifecycle, so it's the error that gets reported.

    Maybe we can add a "check dns" step to give a better error message but DNS failing is generally an exception.

    1 Reply Last reply
    0
  • T Offline
    T Offline
    True
    wrote last edited by True
    #6

    That makes sense, and I support the idea. The error message points the blame to the API and not the DNS. Modifying the error message to check the DNS first definitely saves time on the troubleshooting end and on yours.

    Even if it's the exception the it's worth considering how much time it takes to check for each step during the process. Anyways thanks for the help. You can close this thread 🙂

    1 Reply Last reply
    0

  • Login

  • Don't have an account? Register

  • Login or register to search.
  • First post
    Last post
0
  • Categories
  • Recent
  • Tags
  • Popular
  • Bookmarks
  • Login

  • Don't have an account? Register

  • Login or register to search.