sorted by: new top controversial old
503 error after each login in c/general-discussion@community.nodebb.org
503 error after each login in c/general-discussion@community.nodebb.org
503 error after each login in c/general-discussion@community.nodebb.org
503 error after each login in c/general-discussion@community.nodebb.org
503 error after each login in c/general-discussion@community.nodebb.org
503 error after each login in c/general-discussion@community.nodebb.org
503 error after each login in c/general-discussion@community.nodebb.org
503 error after each login in c/general-discussion@community.nodebb.org
[–] [S] 1 point 8 months ago

We did not modify the bcrypt_rounds parameter. You mean the password hashing in bcrypt could drive a cpu% spike which the traffic management erroneously interprets as too high load?

Does that really sound realistic that the CPU is that busy with a single login and the following hardware - one VM for nodeBB and the same for mongoDB Debian GNU/Linux 13 (trixie), Kernel 6.12.57 4 Cores x86_64 Architektur 8 GB RAM

  • permalink
  • fedilink
  • source
    •
    503 error after each login in c/general-discussion@community.nodebb.org
    503 error after each login in c/general-discussion@community.nodebb.org
    [–] [S] 1 point 8 months ago

    We do not have any traffic right now, nodeBB is runnning with 3 processes each < 1% CPU% and with traffic management enabled and the standard settings we get the 503 once after login. With traffic management disabled the 503 does not happen.

    Can I enable some more debugging/tracing to see why traffic management shuts down the session after login?

  • permalink
  • fedilink
  • source
    •
    503 error after each login in c/general-discussion@community.nodebb.org
    1
    503 error after each login (community.nodebb.org)
     

    We had this 503 error after each login on our older 3.x instance. After a refresh of the page, the session then works fine.

    Now we have installed a plain vanilla 4.6.3 and migrated the mongodb.

    Surprisingly the 503 issue is happening as well on the new instance.

    Setup is with nginx and 3 NodeBB processes on same VM, and Redis cluster

    I assume for some weird reason, the nodebb rate limiting kicks in, but strange that this only occurs after each new login, and reproducible.

    Any suggestions how to diagnose or how to modify the rate limiting check to be less aggressive (or to exclude logins)?

    Thanks Stefan

    error: Error: Command failed: git rev-parse HEA in c/general-discussion@community.nodebb.org
    1
    error: Error: Command failed: git rev-parse HEA (community.nodebb.org)
     

    After installation of 4.6.3 went fine I did some testing and see the below error in logs. I assume this is coming from calling /admin/development/info to fetch the git branch? And I assume it is safe to add the exception as recommended? Thanks Stefan

    2025-11-24T17:09:59.179Z [4567/225367] - error: Error: Command failed: git rev-parse --abbrev-ref HEAD
fatal: detected dubious ownership in repository at '/opt/nodebb'
To add an exception for this directory, call:

        git config --global --add safe.directory /opt/nodebb

    at genericNodeError (node:internal/errors:985:15)
    at wrappedFn (node:internal/errors:539:14)
    at ChildProcess.exithandler (node:child_process:417:12)
    at ChildProcess.emit (node:events:508:28)
    at maybeClose (node:internal/child_process:1101:16)
    at Socket. (node:internal/child_process:457:11)
    at Socket.emit (node:events:508:28)
    at Pipe. (node:net:346:12)
    1
    nodebb-plugin-emoji-android compatibility (community.nodebb.org)
    submitted 8 months ago* (last edited 8 months ago) by to c/general-discussion@community.nodebb.org
    comment fedilink
     

    I have installed vanilla nodebb 4.6.3 After startup I see

    2025-11-22T16:29:06.675Z [4567/162589] - warn: [plugins/load] The following plugins may not be compatible with your version of NodeBB. This may cause unintended behaviour or crashing. In the event of an unresponsive NodeBB caused by this plugin, run `./nodebb reset -p PLUGINNAME` to disable it.
  * nodebb-plugin-emoji-android

    What is the recommendation (other than to disable it)?

    1
    Migration of existing 3.2 instance to new environment with version 4.6 (community.nodebb.org)
     

    Due to problems with our existing nodebb server, where we twice failed to do an in-place upgrade - I would like to check if migrating an older environment to a complete fresh installation is feasible? Database is mongodb 7. The plan would be to backup data from nodebb 3.2.3 and import that to the 4.6.1 instance. Is this feasible at all? Has someone else done something similar? Thanks, Stefan

    view more: next ›