Hi ASCII,

mongod.log should be rotated according to the mongod.properties in Omada controller, but I'm not sure whether it works as expected:

#limit the size of mongodb log, unit is MB.
eap.mongod.log.size.limit=512
eap.mongod.log.rolling.size=50

Anyway, I prefer to place all logfiles (server.log, startup.log and mongod.log) under /var/log/ to where they belong to on Linux systems and to use the existing logrotate mechanism for rotation.

Doing so allows customization of rotation, archiving, cleanup and even mailing of logfiles in a standard way using simple scripts for the logrotate program. It's even possible to append timestamps to rotated logfiles much like mongod does. In my opinion there is no need for developers to implement all those functions in each and every daemon program if they only would obey the UNIX principle »Don't re-invent the wheel again«.

Only problem is that Omada controller's own rotation for the server.log interferes with logrotate to a certain extend. So, Omada controller actually did not only re-invent the wheel, but also added kind of a brake for an existing wheel (unless its built-in rotation can be disabled what I could not yet figure out how to do). :-)
 

ASCII wrote 

It seems like you want an option where mongodb and the controller log via syslog, which shouldn't be to hard to implement, given that the omada controller already has some built in functionality to log to a remote syslog (although this syslog seems incomplete, it doesn't match what I get in server.log).

Indeed, I was able to redirect error and some logging message from Omada controller to the syslog daemon when using start-stop-daemon to run EAP controller V2.x. It's one of the standard features of start-stop-daemon. jsvc can't do this.

And yes, I did suggest this to TP-Link's R&D already several times in last 3 years to use syslog internally, but they decided to not use it.

There is nothing wrong using own logfiles, but my own software lets users choose any logging style: own logfiles, syslogd or even stderr.

By using syslogd the Java code for sending logs to a remote host could be completely removed in Omada controller. 

And by using the system's mongodb package instead of bundling it with Omada controller there would be even more freedom to choose from features of mongod. The community version of Omada controller uses the system's mongodb package, but still requires a separate instance for Omada controller, so if mongod is already used for other databases, there will be two mongod instances running at the end.

Albeit one can define the ports to use for communication of Omada controller with mongod, it's not possible to remove the built-in test whether mongod is running after it has been started by Omada controller. I even was thinking about writing a fake mongod tunnel server for Omada controller, which forwards requests to the system's mongod, thus requiring just one database server instance running.
But hey, I still have a life beside Omada controller. :-)

That's why I requested to fully use the system's mongodb package in the last feature request. mongod can handle more than only one database.

@ASCII, the community version uses standard packages for mongodb and Oracle JRE, but I haven't tested it with latest versions. I still run Debian Jessie for various reasons / dependencies. I had no luck to get Omada controller running with latest JRE one year ago, so I still use JRE 8, albeit a later patch level than what comes with the official Omada controller.

Maybe you have time to check out compatibility with latest JRE? If so, please give feedback here in the forum.