Recently, I set up a new jail to handle my email and so I wanted to increase the number of rotated maillogs to 60 days (from the default 7). I tried to be clever by creating /usr/local/etc/newsyslog.conf.d/maillog.conf with the following line in it: /var/log/maillog 640 60 * @T00 JC and I keeping the maillog entry in /etc/newsyslog.conf alone. I assumed that the .d snippet would *override* the line from the main config file. What ended up happening was that *every* rotated maillog would look like: # bzcat maillog.20241019T000000.bz2 Oct 19 00:00:00 smtp newsyslog[33052]: logfile turned over Oct 19 00:00:00 smtp newsyslog[33052]: logfile turned over I believe that what happened is that newsyslog rotated the log twice every night - first based on the /etc/newsyslog.conf rule and then based on the /usr/local/etc/newsyslog.conf.d/maillog.conf rule. Since there were no log messages from postfix during the few milliseconds between rotations, the log only had the newsyslog markers when it got rotated for the second time and the actual log contents from the first log rotation of the night got lost. (I like timestamp-based log rotation, and so my /etc/crontab has `newsyslog -t DEFAULT`. It is possible that using the regular integer suffixes would have resulted in every-other-log still containing the log messages from the day. I haven't tested it.)
What is the actual bug you are trying to report?
Specifying the same log file name multiple times (across newsyslog.d/*.conf snippets) doesn't result in a single log rotation - it results in the same log getting rotated multiple times resulting in log data loss since the previous rotated log is overwritten by the second/third/etc. rotation.
Btw, this multi-rotation happens completely silently and there is no indication that something like that is happening. I expected one of these instead: 1. take the last entry for each log file name 2. warn if there are multiple instances of the same log file name
(In reply to Josef 'Jeff' Sipek from comment #3) Well, neither is documented in the manpage, I'd say that the behavior you have is undefined.
Agreed. It is currently undefined. IMO it'd be a good thing to allow the "overriding" behavior to make config management easier - rewriting existing files is always more painful than being able to drop a fragment into a .d directory. So, I suppose this ticket is a request to define a behavior - I don't really care how it is defined, but (the current undefined behavior of) silent log file loss is a bad.