Allow logging to stdout/err instead of file

[welshjf]

Perhaps via "LOGFILE: -", or making it the default. Stderr vs stdout doesn't matter to me; stderr would be consistent with gunicorn.

This would allow application log messages to be captured by the supervisor.

• Reduces proliferation of log mechanisms and locations to keep track of (app's messages go to the same place as gunicorn's)
• Avoids the need to reinvent log rotation
• Improves audit security as the app user doesn't need write access to its own logs

[welshjf]

Not sure what you mean to show in trade-manager? I'm not seeing much logging/daemon related.

I don't really believe in daemonization these days, from an architecture standpoint. Why should every app, Python or otherwise, be reimplementing the same boilerplate? And if you daemonize, you then need even more boilerplate in the form of an init script. And an option to run in the foreground, for test/debug or running on non-sysvinit, supervisor-only systems. And pidfiles. And reopening logs after rotation.

Supervisors handle all this and more, without the operator having to learn any app-specific ways of doing things or the developer having to do anything at all. There are several mature, stable options; lately I've been using runit.

[welshjf]

Ultimately, as long as an application has the characteristics of a well-behaved service, I don't much care how it's implemented, but I'm suggesting that taking the supervision approach can save a bunch of work. (Note that I don't consider gunicorn a supervisor, and I haven't dug much into supervisord, so it's possible we're not talking about quite the same thing.) For example DeSW already works fine under this approach, and the logging change in question here is maybe two lines of code. However if your approach yields other benefits I will be interested to see it in practice.

You can handle signals without python-daemon so I'm not sure what value it's adding there.

The aforementioned characteristics include:

• Memorable commands for start, stop, status, and graceful reload if applicable, preferably the same as other system services
• Protection against accidentally starting multiple instances
• Integration with system boot and shutdown
• Log management, mostly as mentioned earlier: rotation and expiration based on configurable criteria; optionally compression; aggregation; privilege separation
• Optionally, automatic restart after unexpected termination