Checked for 12 –> 10 and works. Thanks!

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)

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…

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

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

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.

As said these are 100 500

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

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.

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?

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?

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?