3

I have an existing service, which I'm not able to modify directly—let's say it's closed source, or too complex to edit, or autoupdates and therefore is not a good target for direct modifications.

I would like to run this cleanly in a Docker container, so I need a single foreground process which should live and die with the service, i.e. starting the process should start the service and when the service terminates (e.g. crashes), the root process should terminate as well, so that the Docker container terminates.

Is there a good pattern or existing tool to do this? Ideally, it would redirect the service's stdout/stderr to its own stdout/stderr.

The service has a regular init script and is started via /etc/init.d/myservice start.

What I've seen quite often is the container starting the service and then using tail -n0 -F on some core log file. That works for giving the container some kind of stdout, but if the service ever crashes, the container just goes silent, keeps running and never outputs anything again. There must be a better way, no?

One example for thinking about this could be svnserve. It actually has the --daemon --foreground option which is officially just for debugging, but works. But what if that didn't exist?

1

If the binary is dynamically linked then you can LD_PRELOAD a fork wrapper that does nothing except set a flag the first time it's called, and on subsequent calls sees the flag and acts normally.

If the binary is statically linked then you could ptrace it until its first fork call, skip that call and stop tracing.

On Linux, you can run the daemon in a dedicated PID namespace that just runs a monitoring script as PID 1 in the namespace, and the daemon. When the daemon exits, PID 1 in the namespace, i.e. the monitoring script, receives a SIGCLD.

  • It's not necessarily a binary, and even if it is is launched by a complex init script which I don't want to modify (because it auto-updates every week) and which I don't want to make assumptions of, i.e. that it launches a certain executable at its core (again, because that might be different in the next week). The PID namespacing is interesting, although I don't yet quite understand whether I can do that inside a Docker container. I was hoping that there's a helper tool which I can just hand the initialization script and which does the de-daemonizing for me. – hheimbuerger Jul 6 '16 at 11:09
  • @hheimbuerger Namespaces nest, so there's nothing about being in a Docker container that would make it harder to use a namespace. Whatever method you choose, how the helper script works may matter: if the helper script itself is doing the daemonizing, it's a different problem. Even if the helper script merely runs the daemon binary, but then does other things, some solutions will cause those other things to be done when the daemon exits, others won't. – Gilles Jul 6 '16 at 17:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.