503 error after each login by big_steve in c/general-discussion@community.nodebb.org
[-] big_steve@community.nodebb.org 2 points 5 months ago

Checked for 12 --> 10 and works. Thanks!

503 error after each login by big_steve in c/general-discussion@community.nodebb.org
[-] big_steve@community.nodebb.org 1 points 5 months ago

baris Is it possible to change bcrypt_rounds on an existing system which has already users and (hashed) passwords saved? (I am thinking of reducing the default of 12 to 10 as a test)

503 error after each login by big_steve in c/general-discussion@community.nodebb.org
[-] big_steve@community.nodebb.org 1 points 5 months ago

Can there be another OS config issue on the machine which can cause bcrypt to be that slow? I am thinking of the /dev/random vs. /dev/urandom scenario...

503 error after each login by big_steve in c/general-discussion@community.nodebb.org
[-] big_steve@community.nodebb.org 1 points 5 months ago

Ay, after setting the first parameter to 500, the 503 does not occur anymore. Will dig into testing some more combinations tomorrow. Thanks 🙏

503 error after each login by big_steve in c/general-discussion@community.nodebb.org
[-] big_steve@community.nodebb.org 1 points 5 months ago

I did a quick test with setting the first parameter to 300, did a restart. Logout, login, and the 503 is still there.

503 error after each login by big_steve in c/general-discussion@community.nodebb.org
[-] big_steve@community.nodebb.org 1 points 5 months ago

Thanks, much appreciated. If bcrypt is causing that, then lowering the rounds value should also resolve that, at least for a test. Will post the results.

503 error after each login by big_steve in c/general-discussion@community.nodebb.org
[-] big_steve@community.nodebb.org 1 points 5 months ago

As said these are 100 500

503 error after each login by big_steve in c/general-discussion@community.nodebb.org
[-] big_steve@community.nodebb.org 1 points 5 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

503 error after each login by big_steve in c/general-discussion@community.nodebb.org
[-] big_steve@community.nodebb.org 1 points 5 months ago

Which way is less sensitive - tuning values up or down? Currently they are set to 100 and 500 - and unfortunately the descriptions do not explain their meaning.

503 error after each login by big_steve in c/general-discussion@community.nodebb.org
[-] big_steve@community.nodebb.org 1 points 5 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?

503 error after each login by big_steve in c/general-discussion@community.nodebb.org
[-] big_steve@community.nodebb.org 1 points 5 months ago

I deactivated the traffic management and don't get a 503 anymore after login. But I don't want to completely leave that disabled, should I?

1
503 error after each login (community.nodebb.org)
submitted 5 months ago* (last edited 5 months ago) by big_steve@community.nodebb.org to c/general-discussion@community.nodebb.org
16 comments fedilink

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 by big_steve in c/general-discussion@community.nodebb.org
[-] big_steve@community.nodebb.org 1 points 6 months ago

No, the process was started in that case by root, /opt/nodebb is owned by user nodebb I assume I need to start under user nodebb?

1
error: Error: Command failed: git rev-parse HEA (community.nodebb.org)
submitted 6 months ago by big_steve@community.nodebb.org to c/general-discussion@community.nodebb.org
3 comments fedilink

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 6 months ago* (last edited 6 months ago) by big_steve@community.nodebb.org to c/general-discussion@community.nodebb.org
0 comments 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)
submitted 6 months ago by big_steve@community.nodebb.org to c/general-discussion@community.nodebb.org
2 comments fedilink

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 ›

big_steve

joined 2 years ago