+1 for concept and rationale Might be good to survey the common log rotation tools to verify custom signals are supported.
On Thu, Jan 23, 2020 at 11:16:25AM -0600, Brian Neradt wrote: > > Context > ====== > > Traffic Server currently implements its own mechanism for rotating its logs > and cleaning up (i.e., deleting) rotated logs based upon configured > constraints. These features seem to have been developed at a time when > third party tools for managing such logs were non-existent or immature. > Today administrators have tools such as logrotate they can use to manage > logs. Such tools handle log rotation and deletion (and compression, > automated emailing, and other related features) in a way that > administrators are generally familiar with and would prefer to use for > consistency across their log management needs. After rotating their logs, > these tools send a signal to the process generating the logs so they can > close and re-open the logs. Traffic Server does not currently support > external log managers because it does not support listening for such > signals. > > Proposal > ======= > > In order to support the use of tools such as logrotate, this proposal > suggests adding support for Traffic Manager and Traffic Server to handle a > signal that causes those processes to close and re-open their logs handles. > > Further, while SIGHUP is a pretty common signal used for such purposes, > this proposes SIGUSR2 instead since we already use that for traffic.out > (added via https://github.com/apache/trafficserver/pull/274/files). > > > Please share any thoughts or suggestions. > > Thanks, > Brian > -- > "Come to Me, all who are weary and heavy-laden, and I will > give you rest. Take My yoke upon you and learn from Me, for > I am gentle and humble in heart, and you will find rest for > your souls. For My yoke is easy and My burden is light." > > ~ Matthew 11:28-30
