Re: [List] pf log files

On 25/07/2026 02:30, Doug Hardie wrote:
>> On Jul 24, 2026, at 14:41, Frank Leonhardt <[email protected]> wrote:
>>
>> On 24/07/2026 09:17, Doug Hardie wrote:
>>> pf is logging as directed in pf.conf.  it creates the file pflog in /var/log.  However, there are a bunch of pflog.bad.nnnnnnn files where the n's appear to be random characters.  Each of them has only one line like:
>>>
>>> Jul 20 00:00:00 mail newsyslog[69857]: logfile turned over
>>>
>>> There is no pflog.bad entry in /etc/newsyslog.conf  The conf.d entry in newsyslog.conf is commented out.  What is generating these files?  Can it be disabled?
>>>
>> Donno, but I can guess, as usual.
>>
>> I don't think syslog or pf is creating them; newsyslog is.
>>
>> Can you run this:
>>
>> newsyslog -nrv
>>
>> It'll list all the stuff newsyslog is going to do from all the config files.
>>
>> Now my guess is that newsyslog is rotating /var/log/pflog every night using the wrong flags. On my system (in front of me) its in /etc/newsyslog.conf.d/pf.conf and the line looks like this:
>>
>> /var/log/pflog                          600  3     1000 *     JB   /var/run/pflogd.pid
>>
>> Note the 'B' flag - it's important because it's telling it it's a binary file. If it's a text file newsyslog will add a line saying it's been turned over, very much as you describe. I think you'll find B is missing somewhere.
>>
>> End of Part 1
>>
>> So where are the .bad. files coming from?
>>
>> When the file is rotated it will send a SIG to restart pflogd, which will go to it's log file and discover it's no longer a pcap file. Rather than clobber it completely, it renames it using a function mkstemp() looking at the format of the .bad file, and create a new pflog binary file to log to.
> Digging through pflogd source, I find that is exactly what is happening.  I don't see any easy way to prevent that without compromising the functioning of other log files.  I guess I will need to daily prune those files as they serve no useful purpose.
>
>> End of Part 2
>>
>> Well that's my theory. What I can't tell you is where the bad entry is coming from. Perhaps it's defaulted to something else if you've commented out the correct entry in /etc/newsyslog.conf.d/pf.conf ?
>>
>> So let's see the output of newsyslog -nrv ? And perhaps also:
>>
>> grep -n pflog /etc/newsyslog.conf /etc/newsyslog.conf.d/*.conf /usr/local/etc/newsyslog.conf.d/*.conf
>>
>> Regards, Frank.
>
> mail# newsyslog -nrv
> Processing /etc/newsyslog.conf
> Found: <include> /usr/local/etc/newsyslog.conf.d/[!.]*.conf
> /var/log/auth.log <7Z>: --> will trim at Thu Dec 31 23:00:00 2026
> /var/log/console.log <5Z>: size (Kb): 51 [100] --> skipping
> /var/log/cron <3Z>: size (Kb): 99 [100] --> skipping
> /var/log/daily.log <7Z>: does not exist, skipped.
> /var/log/debug.log <7Z>: --> will trim at Sat Jul 25 00:00:00 2026
> /var/log/maillog <21Z>: --> will trim at Sat Jul 25 00:00:00 2026
> /var/log/maillist <32Z>: --> will trim at Sat Jul 25 00:00:00 2026
> /var/log/imaplog <21Z>: --> will trim at Sat Jul 25 00:00:00 2026
> /var/log/messages <5Z>: --> will trim at Sat Jul 25 00:00:00 2026
> /var/log/monthly.log <12Z>: does not exist, skipped.
> /var/log/pflog <3Z>: --> will trim at Sat Jul 25 00:00:00 2026
> /var/log/ppp.log <3Z>: size (Kb): 0 [100] --> skipping
> /var/log/security <10Z>: size (Kb): 0 [100] --> skipping
> /var/log/sendmail.st <10>: does not exist, skipped.
> /var/log/daemon.log <5Z>: --> will trim at Sat Jul 25 00:00:00 2026
> /var/log/utx.log <3>: --> will trim at Sat Aug  1 05:00:00 2026
> /var/log/weekly.log <5Z>: does not exist, skipped.
> /var/log/xferlog <7Z>: size (Kb): 1 [100] --> skipping
> mail#
>
> mail# grep -n pflog /etc/newsyslog.conf /etc/newsyslog.conf.d/*.conf /usr/local/etc/newsyslog.conf.d/*.conf
> /etc/newsyslog.conf:27:/var/log/pflog				600  3	   *	@T00     ZC    /var/run/pflogd.pid
> /etc/newsyslog.conf.d/pf.conf:1:/var/log/pflog				600  3	   1000	*     JB    /var/run/pflogd.pid
> mail#
>
>
> However, note that /etc/newsyslog.conf has at the end:
>
> #<include> /etc/newsyslog.conf.d/[!.]*.conf
> <include> /usr/local/etc/newsyslog.conf.d/[!.]*.conf
>
>
> /usr/local/etc/newsyslog.conf.d does not exist.
>
It looks like my guess was right. "newsyslog -nrv" is showing you what 
newsyslog would do; which files it would process and how it's 
interpreting them. As you can see it's trimming /var/log/pflog at 
midnight. You say you have commented out the include files, which looks 
to have worked, which is why you're getting this odd line from 
/etc/newsyslog.conf itself. And indeed it doesn't have the B flag so 
when it rotates it's adding a line of text, which pflogd is realising 
isn't a valid pcap file when it tries to open it so it renames it as 
*.bad.<random> and creates a new one.

I don't know why you've disabled all the entries in newsyslog.conf.d/ 
but assuming you have your reasons your best course is to copy the 
correct line in newsyslog.conf.d/pf.conf in place of your broken line 27 
in newsyslog.conf. Your existing line 27 looks okay apart from the B 
being missing, although the C (create new file) is redundant as pflogd 
would do that anyway, and looking at the source code this might also 
mess things up.

Where I guessed wrong(!) is on pflogd logic in creating the 
pflog.bad.xxxxx file using mkstemp(). It actually happens in a function 
called move_log() in privsep.c around like 200.

The function that rejects your text file is scan_dump() round about 400 
in the main source file - it fails as soon as it tries to read the magic 
number for a pcap file. If you go back to privsep.c (which is where it 
messes with the files using an elevated privilage) you can see it's in a 
forever loop creating temp files and checking headers until it gets a 
good one. So I suspect your C to create may also be causing a problem as 
newsyslog giving it an empty file is going to result in a bad header too.

Anyway, having had a good look at the source code I'm certain - it's 
your unorthodox entry in newsyslog.conf interacting with pflogd's 
expectation of a pcap format file. You need to fix it. I suggest:

/var/log/pflog    600  3      1000    *     JB /var/run/pflogd.pid

Remember that newsyslog.conf is whitespace separated and empty fields 
are detected by looking at the content of what it finds. For example the 
missing user:group field here is considered blank because it doesn't 
find a : character, so it goes on to the next field (file permission). A 
common confusion - the parser is trying to be too clever if you ask me.

Regards, Frank.