Assuming I was starting a project where I am allocating portions of the profit to entities that offer us free things such as forum software to house community chit chat... who/where would I donate to in order to support NodeBB?

Looks like moving to the latest node.js did not help. Just happened again.

Bad news is that I crashed with absolutely no errors a few minutes ago. The good news is that it actually recovered on it's on in dev mode. I'll try updating nodejs as recommended.

@LukeLaupheimer That's beautifully terrible. Once it crashes again and I (maybe) get some useful info.. I'll do something like that.

I don't ruby. Is that a loop? Or do I need to set a cron to run it every x minutes? Also.. my http is a 301 to https. Will that work with https also?

@yariplus I'm on stable.

@boomzilla Thanks for the info. I'm on CentOS and not using docker. I'll take a look at that sometime soon. It's late thought and it's been a long day.

@pichalite That'd work if I didn't just scp it to another server.

@yariplus Good question. I'm honestly not sure. I just followed the install directions. I think I'm on the stable. :3 Is there an easy way to tell? My logs just say "Initializing NodeBB v1.0.3".

• What's your servers hardware?
  Core i3-2130/3240 3.4 GHz+ | 8 GB Ram
• What operating system runs on your server?
  CentOS 7.2
• What's your Redis Mongo version?
  mongodb 3.2.7
• What's your NGINX version?
  nginx 1.6.3
• What's your NGINX config?

server {
    listen         80;
    server_name     domain.com www.domain.com;
    return         301 https://www.domain.com/$request_uri;
}
server {
    ssl_certificate /etc/letsencrypt/live/www.domain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/www.domain.com/privkey.pem;

    listen 443 ssl;

    add_header Strict-Transport-Security "max-age=31536000";
    server_name www.domain.com;

    location / {
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $http_host;
        proxy_set_header X-NginX-Proxy true;

        proxy_pass http://127.0.0.1:4567/;
        proxy_ssl_session_reuse off;
        proxy_redirect off;

        # Socket.IO Support
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

• What else is running on the server which might interfere with NodeBB / Redis (especially IO extensive tasks like backups)?
  Confluence. The server doesn't even hiccup right now though. Not much traffic.
• Is your server using swap at all / a lot of swap during the times of lag?
  Negative. It's not lag. The server just stops.. but the daemon stays up. The only fix is to kill the service and start it up again
• Have you tried running NodeBB in verbose mode?
  Not recently. Running in dev and logging to a file now. I'll provide relevant stuff the next time it crashes.

You aren't alone here. I've been dealing with the same thing. It weird because the supervisor service still sees it as online, but nginx returns a 502. I have yet to find a good way to deal with this. It seems to have started on 1.0.3, so I've been considering going back down to 1.0.2.

Ahh. Gotcha. Thanks for that. I'll submit an issue.

This seems to be broken in the latest NodeBB. I'm having issues with it freezing up on a post & posting a blank post with no content. Author seems to have removed github. Are you no longer maintaining this @lewismcmahon?

Just an update for anyone who gets this in the future, if you use cloudflare's caching on the forum.. try switching it into dev mode and do a test on an incognito window. If you no longer see it, cloudflare is the issue. I tried just about every setting I could find on my free account and nothing seemed to fix the issue. For now I have just removed the caching from my forum. If any of y'all end up finding an answer, let me know. I'll do the same.

I'm just now starting to experience this now. I don't know if I can attribute it to any changes in particular I made, but it happens even on "fresh" sessions (phone I've never used on the forum before, incognito sessions, etc.). Unlike OP. I can still login though.

Edit: I hate to say it, but this seems like another cloudflare caching issue. I'm looking into it now, but it only happens on my cloud URL and not my "live" url.

@lenovouser said:

@L33t Yes, that is normal. An established WebSocket connection is not "closed" until you close the tab. That's why it shows up with so many seconds. You can happily ignore that

Thanks for the clarification. I kinda figured as much, but wanted to make sure.

This tutorial is awesome. I was having a terrible time because I was getting weird 400 errors in new relic for socket.io. The odd thing is that my apdex for NodeBB is terrible and transactions for socket.io are showing as ~30,000ms.

http://d.l33t.tech/121fp/4V5UUDRS

Anyone have ideas for why this would be?

@codecowboy said:

@julian thanks. I managed to restore the database but I have messed things up as I thought I would try and be secure and add a username/password within mongo.

Is there a way to specifify the authentication database here ?

    "url": "http://localhost:4567",
    "secret": "****",
    "database": "mongo",
    "mongo": {
        "host": "127.0.0.1",
        "port": "27017",
        "username": "***",
        "password": "****",
        "database": "0"
    }

I added the user to the admin database like this:

{

user:"****",

pwd:"****",

roles: [ { role: "userAdminAnyDatabase", db: "admin" } ]
})

My NodeBB database is 0

@L33t why is it 'no good' ?

The authentication database should be the same database as your forum database. You just add a user to it in the mongo cli.

It's no good because it won't let you run the setup. If I remember right, it errors out and says it can't create the records it needs or something. It's easiest to just restore and copy over files and I'm not sure if there really is another way.

I just did this. Restoring mongodb & trying to run ./nodebb setup is no good. Just copy over your old forums files and modify the config file if necessary (ip of mongodb, user/pass if changed).

Interesting. I'll have to keep this one in my back pocket for the future.

@phit I get that, but why would the issue be intermittent? I.E. I load the same page twice. It works 70% of the time and 30% of the time it doesn't.

This actually seems to help. Is there a particular logic behind that suggestion or why it would fix it?