This morning, I was having an issue where my cloud key appear to be running (SSH and the webui at :443 was up) but I couldn't connect to the controller interface on port 8443.
Having SSH'd onto the cloudkey and looking at the logs at /usr/lib/unifi/logs/server.log
I found the following:
Sun Feb 14 05:38:37.472 [initandlisten] couldn't uncompress journal section
Sun Feb 14 05:38:37.472 [initandlisten] Assertion: 15874:couldn't uncompress journal section
Along with a stacktrace.
I tried the mongodb repair steps (detailed here on this ubiquiti support doc):
service unifi stop
mongod --dbpath /usr/lib/unifi/data/db --smallfiles --logpath /usr/lib/unifi/logs/server.log --repair
But this wasn't working for the same reason as before:
Sun Feb 14 05:38:37.349 [initandlisten] MongoDB starting : pid=5133 port=27017 dbpath=/usr/lib/unifi/data/db 32-bit host=UniFi-CloudKey
Sun Feb 14 05:38:37.349 [initandlisten]
Sun Feb 14 05:38:37.349 [initandlisten] ** NOTE: This is a 32 bit MongoDB binary.
Sun Feb 14 05:38:37.349 [initandlisten] ** 32 bit builds are limited to less than 2GB of data (or less with --journal).
Sun Feb 14 05:38:37.349 [initandlisten] ** See http://dochub.mongodb.org/core/32bit
Sun Feb 14 05:38:37.350 [initandlisten]
Sun Feb 14 05:38:37.350 [initandlisten] db version v2.4.10
Sun Feb 14 05:38:37.350 [initandlisten] git version: nogitversion
Sun Feb 14 05:38:37.350 [initandlisten] build info: Linux hartmann 3.16.0-4-armmp-lpae #1 SMP Debian 3.16.39-1 (2016-12-30) armv7l BOOST_LIB_VERSION=1_55
Sun Feb 14 05:38:37.350 [initandlisten] allocator: system
Sun Feb 14 05:38:37.351 [initandlisten] options: { dbpath: "/usr/lib/unifi/data/db", fork: true, journal: true, logpath: "/usr/lib/unifi/logs/server.log", smallfiles: true }
Sun Feb 14 05:38:37.365 [initandlisten] journal dir=/usr/lib/unifi/data/db/journal
Sun Feb 14 05:38:37.366 [initandlisten] recover begin
Sun Feb 14 05:38:37.367 [initandlisten] recover lsn: 1445614575
Sun Feb 14 05:38:37.367 [initandlisten] recover /usr/lib/unifi/data/db/journal/j._3
Sun Feb 14 05:38:37.367 [initandlisten] recover skipping application of section seq:849558263 < lsn:1445614575
Sun Feb 14 05:38:37.368 [initandlisten] recover skipping application of section seq:849795783 < lsn:1445614575
Sun Feb 14 05:38:37.368 [initandlisten] recover skipping application of section seq:849855173 < lsn:1445614575
Sun Feb 14 05:38:37.368 [initandlisten] recover skipping application of section seq:850033273 < lsn:1445614575
Sun Feb 14 05:38:37.368 [initandlisten] recover skipping application of section seq:850152043 < lsn:1445614575
Sun Feb 14 05:38:37.368 [initandlisten] recover skipping application of section seq:850448853 < lsn:1445614575
Sun Feb 14 05:38:37.368 [initandlisten] recover skipping application of section seq:850745663 < lsn:1445614575
Sun Feb 14 05:38:37.368 [initandlisten] recover skipping application of section seq:850923813 < lsn:1445614575
Sun Feb 14 05:38:37.368 [initandlisten] recover skipping application of section seq:850983203 < lsn:1445614575
Sun Feb 14 05:38:37.368 [initandlisten] recover skipping application of section more...
Sun Feb 14 05:38:37.427 [initandlisten] recover /usr/lib/unifi/data/db/journal/j._4
Sun Feb 14 05:38:37.472 [initandlisten] couldn't uncompress journal section
Along with a similar stack trace as before.
To fix it I took the same step as described in the instructions for debian (which are bit lower down on the same support article)
It says:
In some cases, where the journal is corrupted, it will be helpful to run the following command before repairing the database, to move it to another location:
The command to run is this one:
mv -vi /usr/lib/unifi/data/db/journal /usr/lib/unifi/data/db/journal-$(date -I)
Having run that, re-run the repair:
mongod --dbpath /usr/lib/unifi/data/db --smallfiles --logpath /usr/lib/unifi/logs/server.log --repair
And that should sort it (check the logs to see). After that, all you need to do now is re-start the unifi service:
service unifi start
If all is well, you should find the unifi controller interface is now back up and running on port 8443.