Docker - capturing logs when replacing PID 1
I have actively been looking for info on the internet concerning this, but it seems to be a somewhat particular use case.
I am trying to deploy a docker container running a legacy back-end in a Kubernetes/Openshift cluster.
The container is started using an entrypoint.sh script which will initialize dependencies that the back-end requires before booting.
I want the back-end as PID 1 - as to capture the back-end logs with docker/openshift.
To do this I have an exec command at the end of the entrypoint.sh script which launches my back-end and which thus replaces the entrypoint.sh process - which is assigned PID 1 by docker - with my back-end.
The problem:
At the moment the exec is executed in the entrypoint.sh, docker stops capturing the logs, and I thus don't have any logs from my back-end process captured by docker when performing "docker logs $MY_CONTAINER_ID".
When entering the container, I do see that everything functions properly:
My back-end process is running as PID 1, and the process file descriptors 1/2 are correctly setup capturing STDOUT and STDERR of my back-end process.
Does anyone know if this is a missing configuration issue? Or is docker simply designed to work like this considering that I am replacing PID 1 with exec?
Similar Questions
2 Answers
I figured out the issue:
The back-end is in fact setup to create symbolic links between STDOUT and STDERR to log files in the container itself. For example: the applicative code logs on STDOUT and the back-end boot script redirects STDOUT to a log file (legacy app...).
The docker container natively uses a pipe process for STDOUT and STDERR when executing the entrypoint.
The problem:
When the back-end process replaces the entrypoint.sh process at the end, the STDOUT and STDERR symlinks change - as mentioned above, and I guess this has an affect on the docker deamon and stops docker from collecting any further logs on STDOUT and STDERR.
I can't see anything wrong in what you are describing. The stdout/stderr of process ID 1 should be captured, as will any sub process if they inherit stdout/stderr of the parent process (process ID 1).
Where you can have problems is if an application is set up to log to a normal file and doesn't use stdout/stderr. In these cases if they will only accept a file, use /proc/1/fd/1 as the log file path. This will result in the log messages getting output through stdout of process ID 1.
Do note that if your application uses a logging framework that wants to do its own log file rotation on the path you give it, you will need to disable that, you want it to keep using the same file path and not try and rename or truncate it.