Yup. If your app's parent process crashes, its child processes may now be orphans. However in this case your monitoring should also restart the entire container.
2. Logging.
Assuming you run your docker image in a .service file (which is what CoreOS uses as standard), systemd-journald on the host will log everything as coming from whatever your unit (.service) name is. So if you `systemctl myapp start` output and errors will show up in `journalctl -u myapp` in the parent OS.
3. Scheduled tasks.
For things like logrotate, it really depends whether you're handing logs inside or outside the container. Again, I'd use systemd-journald in CoreOS, rather than individual containers, for logs, so they'd be rotated in CoreOS. For other scheduled tasks it depends.
4. SSHd
It depends. SSH isn't the only way to access a container, you can run `lxc-attach` or similar from the host to go directly to a container.
I do mention CoreOS here because that's what I use, but RHEL 7 beta, recent Fedoras, and upcoming Debian/Ubuntus would all operate similarly.
Regarding reaping orphans: orphans do not necessarily imply that something crashed or that something went wrong. Orphans is a very normal part of system operation. Consider an app that daemonizes by double forking. Double forking a common technique with the intention of making the process become adopted by init. It expects PID 1 to be able to handle that correctly.
Regarding logging: that only holds for output that is written to the terminal. There are lots of software out there that never log to the terminal and log only to syslog.
As for all the other stuff: it is up to debate whether they should be handled inside or outside the container. The right solution probably varies in a case-by-case basis. Baseimage-docker's point is not to tell that everyone must do things the way it does. It's to provide a good and useful default, for the people who have no idea that these issues exist. If you are aware of these issues and you think that it makes sense to do things in another way, go ahead.
> Consider an app that daemonizes by double forking. Double forking a common technique with the intention of making the process become adopted by init.
But that's daemonization - if you don't daemonize (because your container is itself a daemon) you won't need it.
Ack re: syslog. The stuff I'm writing now uses stdout, and I let systemd do the work. If I had some proprietary app that needed a local syslog then I'd run that in the container. But I'd more likely ask the vendor if I could just disable the syslog requirement and either get stdout or journald for things like multiple field support etc.
The reason I'm writing is because the post gives the impression that everyone is likely to be 'doing it wrong'. There are definitely some things to consider, but I don't think that impression is accurate.
Correct, but how do you know your app never spawns anything that may daemonize? If you wrote your app yourself and know all your dependencies and how everything behave, then fine. But what if you're simply packaging someone elses app? What if you're building a database server container? Have you read every single source line to be sure that it will never behave that way and leave behind zombie processes?
That is what baseimage-docker is about. It's about providing a sane, safe default that behaves correctly. There are also other ways to make your system behave correctly of course.
As for "giving the impression that everything else is wrong": that is not the intent of the article. The title is only to catch the reader's attention and to encourage the reader to continue reading and to understand the edge cases. The title says other things MIGHT be wrong, it does not say that they ARE wrong. So let me make it clear: any solution which solves the edge cases and issues described in the article, is correctly. Baseimage-docker is one solution, the one provided by us. It is not the only possible solution.
I even asked on ServerFault (ie, StackOverflow for servers) about it and was told, quite aggressively, that running a full OS is wrong:
http://serverfault.com/questions/573378/how-can-i-persistent...
Addressed individually:
1. Reaping orphans inside the container.
Yup. If your app's parent process crashes, its child processes may now be orphans. However in this case your monitoring should also restart the entire container.
2. Logging.
Assuming you run your docker image in a .service file (which is what CoreOS uses as standard), systemd-journald on the host will log everything as coming from whatever your unit (.service) name is. So if you `systemctl myapp start` output and errors will show up in `journalctl -u myapp` in the parent OS.
3. Scheduled tasks.
For things like logrotate, it really depends whether you're handing logs inside or outside the container. Again, I'd use systemd-journald in CoreOS, rather than individual containers, for logs, so they'd be rotated in CoreOS. For other scheduled tasks it depends.
4. SSHd
It depends. SSH isn't the only way to access a container, you can run `lxc-attach` or similar from the host to go directly to a container.
I do mention CoreOS here because that's what I use, but RHEL 7 beta, recent Fedoras, and upcoming Debian/Ubuntus would all operate similarly.