I wonder if a very simple solution would be enough: with a one-line change, the logs could be created as named pipes instead of files. Then you could just write some upstart scripts/systemd units that do

    cat /run/docker/mypipe >/dev/log

And you'd be good.

---

I'm not sure this is the right approach, though. In my opinion, docker shouldn't log at all—containers are unix processes, and Unix processes log to ephemeral stream-sink endpoints (think AWS SNS topics) called stdout and stderr. To collect and persist those logs, the Unix Way is to use shell redirection to "attach" those endpoints to subscribers.

Now, in Docker's daemonized run mode, these pipes are just hanging loose. But docker provides the "docker attach" command precisely so you can reattach them to something (or as many somethings) as you like. All you have to do if to get sensible logging if you're using e.g. Upstart is to create a service that runs "docker attach <mycontainer>": the logs will flow from the container's stdout/stderr to the service's stdout/stderr, and Upstart will catch them and handle them sensibly from there.

So, having done something like that, the important bit would actually be making sure docker doesn't do its own broken logging at all, except in the case of test containers that will never be attached to. Actually, this also cuts across the use (or lack thereof) of the --rm flag: it'd make sense for containers started with --rm to not log. (The generalization of the --rm semantics would seem to put such containers in the same category as e.g. EC2 instance-store instances.)