There have been several bugreports, but no solution.
Note: the problem is that the log rotation isn't shipped with the container but left out, which is a headache to deploy and administer as you work with different deployment methods and deploy in dynamic environments (which kind of is the point of docker).
zabbix-snmptraps should of course log rotate its own logs, or you're forced to various hacks to make it actually work and be useful.
You cannot logrotate snmptrapd's logfile without sending a signal to the snmptrapd process to reload the logfile. Doing this between containers is madness and unprofessional, but can be done with hacks.
What this means, is that a sidecar with logrotate will just unlink a file that's not really deleted or logrotated until the zabbix-snmptrapd container stops.
Since there will not be a bugfix for this, then what's the most stable workaround to logrotate this container?
Note: the problem is that the log rotation isn't shipped with the container but left out, which is a headache to deploy and administer as you work with different deployment methods and deploy in dynamic environments (which kind of is the point of docker).
zabbix-snmptraps should of course log rotate its own logs, or you're forced to various hacks to make it actually work and be useful.
You cannot logrotate snmptrapd's logfile without sending a signal to the snmptrapd process to reload the logfile. Doing this between containers is madness and unprofessional, but can be done with hacks.
What this means, is that a sidecar with logrotate will just unlink a file that's not really deleted or logrotated until the zabbix-snmptrapd container stops.
Since there will not be a bugfix for this, then what's the most stable workaround to logrotate this container?
Comment