问题
12factor recommends not to daemonize processes. What are the disadvantages of doing so?
回答1:
They are looking not at the daemon process itself, but at managing that process and ensuring it's running properly. They cite instances of kludgey frameworks built around daemons where the daemon was not written with an eye towards that management, thus requiring an excess of resources to restart it, clean up after it, etc.
They point out and recommend the use of system management facility software, including smf (Solaris), upstart (Linux), launchd (OSX), and even hoary old init and ttys (older Unix versions and BSD based distros). They don't mention systemd (also Linux), but that could be timing. They also don't mention inetd or xinetd that also make management and restart of network based daemon processes easy and simple.
So they aren't really recommending not to daemonize processes; they're recommending that after you invent your nifty daemon service process, you don't reinvent a management framework around it. Develop your server with an awareness of how it will be managed, and that will likely make the total effort involved much less. In current terms, this is a devops attitude.
回答2:
I would add to the list of supervisors, immortal A *nix cross-platform (OS agnostic) supervisor that simplifies the 12 factors practices.
timestamp
By default the option timestamp within the log is set to false, this is in favor of applications that follow the 12 factor and in cases where log is structured “JSON”, it could be parsed easily.
回答3:
Basically the intention is to remove the service management logic from the container and have it as part of the infrastructure
consider the scenario of a service that crashes - instead of restarting the service within the image, which may not help in cases where the server is loaded or malfunctioning, the infrastructure may decide to restart it on a different server
来源：https://stackoverflow.com/questions/26706240/why-does-12factor-recommend-not-to-daemonize-processes