Nodebb service failing to start after server reboot

[newnodebbuser]

OS: Ubuntu 16.04
node version 6.10.3

I followed the setup documentation that defines setting up the nodebb service but after a server reboot my service fails to load. The initial service, prior to reboot, was working fine and I got as far as creating my proxies to make the site reachable by domain.

My nodebb.service is a copy/paste from the docs:

--
[Unit]
Description=NodeBB forum for Node.js.
Documentation=http://nodebb.readthedocs.io/en/latest/
After=system.slice multi-user.target

[Service]
Type=simple
User=nodebb

StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=nodebb

Environment=NODE_ENV=production
WorkingDirectory=/opt/nodebb
ExecStart=/usr/bin/node loader.js --no-daemon --no-silent
Restart=always

[Install]
WantedBy=multi-user.target

The service starts after $sudo service nodebb start but then fails.
After start:

After checking status <5 seconds later:

I'll admit I'm not the most *nix savvy, so this may be simple user error. I found this that mentioned something about non-existing /html/ directories but I don't know what that means in regards to the nodebb.service.

[newnodebbuser]

After running ./nodebb dev, it seems my mongo database is down and the service isn't starting correctly.

I'm assuming this is because I didn't cleanly shut this VM down. I assume a clean shutdown for nodebb would require stopping both the nodebb and mongod services, correct?

Because now when I try to start mongod, I get errors on that front too. Note I already deleted mongod.lock

It looks like the culprit is now an unclean shutdown of the mongodb service. Any suggestions?

For the mongod, so far I have:

• verified the mongod.service exists
• sudo systemctl mongod start
• sudo service mongod status <- still shows as failed

[julian]

NodeBB (for obvious reasons) requires MongoDB to be running so it can start. So the problem here is MongoDB isn't running, as you've figured out.

If MongoDB won't start via the service handler, check the logs to see what went wrong. They're likely in /var/log/mongodb