So I am developing a script that takes traefik logs, 'enhances' them with additional info and sends them to my log aggregator.
The issue comes when I try to rotate the log files, I compress the old log file, create an empty file, send a USR1 signal and expect the logging to continue as normal the new empty file. This works fine for the access log but for the process log stays empty as if traefik is trying to write to the old file.
And it seems that this is be design as you can see in the source for server/server_signal.go when traefik receives a USR1 signal only the function to rotate the Access log is called skipping over process log.
Below is the section I am referring to , and so my question is whether this is done on purpose or some kind of oversight? I was about to make a bug report assuming it was an oversight but now I am questioning myself and whether this is done on purpose for some reason that I cant seem to figure out. It seems logical and correct to handle a signal consistently for all logs not just a single log. My process log grows quicker than access log so it would be really nice and helpfull to have this functionality the way I assume is the correct/intended way.
Can anyone shed light on the reasoning behind this, if there is a reason at all.
func (s *Server) listenSignals(ctx context.Context) {
for {
select {
case <-ctx.Done():
return
case sig := <-s.signals:
if sig == syscall.SIGUSR1 {
log.Info().Msgf("Closing and re-opening log files for rotation: %+v", sig)
if err := s.observabilityMgr.RotateAccessLogs(); err != nil {
log.Error().Err(err).Msg("Error rotating access log")
}
}
}
}
}