Each running process writes its event stream, unbuffered, to
Every decent process manager like systemd or docker take care of log management features like:
- Storage driver
Therefore, you should not implements log management aspects in your application.
Log to stdout and the underlying infrastructure will do the job.
But sometimes, you have to package or containerize an application that breaks this law and log its events into files… Here is two ways to get rid of the problem based on the awesome fact that everything in Linux is a file:
stdout => /proc/self/fd/1
If an application can write to log file, it probably can write to
/proc/self/fd/1 and thus,
1. There is a parameter for you
Many applications are logging to file by default but sometimes they allow you to configure some attributes related to logs. For example, in Apache2, you can specify:
CustomLog /proc/self/fd/1 combined
CustomLog sets log filename and format. If you configure
/proc/self/fd/1 as the log filename, Apache2 process will now write to its own stdout.
2. Symbolic Links
If the application logs to an hard coded path, you can trick the program by creating a symlink in place of the real log file before starting the application.
ln -sf /proc/self/fd/1 /var/log/myapp.log
Please ensure there is no active logrotate script managing this file. Despite the fact that the rotation should be cancelled by a security component, this is not an excuse to let unmanaged things in place.
logrotate: log /var/log/myapp.log is symbolic link. Rotation of symbolic links is not allowed to avoid security issues -- skipping.
You have to be careful with this craftiness. You don’t really know how the application will open and manage the log file descriptor. These techniques had always worked for us but be sure to test things very carefully before shipping this kind of hacks into production.