newsyslog R flag

Hello community,

I have a problem with newsyslog(8) and the R flag, specified in newsyslog.conf(5) entry. The man page states:

Code:
R	     if this flag is set the newsyslog(8) will run shell com-
		     mand defined in path_to_pid_cmd_file after rotation
		     instead of trying to send signal to a process id stored
		     in the file.

I have recently installed and configured Unbound recursive, validating resolver and have set up, in /etc/newsyslog.conf, a logging policy to keep the logs for the past 366 days (one year).

/etc/newsyslog.conf entry follows:
Code:
/var/log/unbound/unbound.log    unbound:wheel   640     366     *       @T00    XCR     /usr/local/etc/unbound/unbound-reopen-log-file

/usr/local/etc/unbound/unbound-reopen-log-file contents:
Code:
#!/bin/sh
#
# This small script reopens the log file after log rotation
# by newsyslog(8).

# Reopen the log
/usr/local/sbin/unbound-control log_reopen

# Show me that you've been executed successfully 
/usr/bin/touch /usr/local/etc/unbound/run

exit 0

Unbound has a control interface that allows you to set/unset parameters and a bunch of other things like dumping the cache, loading the cache from a file, etc. One command allows the operator to close and reopen the log file.

The reasoning behind using # unbound-control log_reopen instead of sending the HUP signal is that Unbound keeps the cache in memory and at HUP signal the cache is lost. I don't want to invalidate the cache each evening. My network is rather small but I will be using Unbound in rather large networks in the future where the cache really matters.

I have copied the Unbound /etc/newsyslog.conf entry into a new file so I can debug it and run # newsyslog -vF -f newsyslog.debug. The output follows:

Code:
Processing newsyslog.debug
/var/log/unbound/unbound.log <366X>: --> trimming log....
Signal all daemon process(es)...
Pause 10 seconds to allow daemon(s) to close log file(s)
Compress all rotated log file(s)...
newsyslog: log /var/log/unbound/unbound.log.0 not compressed because daemon(s) not notified

The logs don't get compressed and the /usr/local/etc/unbound/run file doesn't get created. The outcome is that Unbound doesn't log anymore until restart or # unbound-control log_reopen command run.

I have even traced the above newsyslog(8) command using ktrace(1) and searched the ktrace.out file for /usr/local/sbin/unbound-control log_reopen occurrences. There is just one occurrence, when the file is loaded in memory. Below is the section of ktrace.out pointing that out:
Code:
46524 newsyslog RET   fstat 0
 46524 newsyslog CALL  read(0x3,0x800c0d000,0x1000)
 46524 newsyslog GIO   fd 3 read 155 bytes
       "### ---Unbound logs
        /var/log/unbound/unbound.log    unbound:wheel   640     366     *       @T00    XCR     /u\
        sr/local/etc/unbound/unbound-reopen-log-file
       "

Do you have any idea how can I fix this besides sending the HUP signal to Unbound which results in invalidating the cache.

Thank you, Cheers and Goodwill.
 
Hello again,

I forgot to mention that I am running FreeBSD 9.0-STABLE. I have just noticed that the same thing happens with NSD (Name Server Daemon) entry from /etc/newsyslog.conf. The policy is the same, keep the logs for 366 days, compress them using xz(1), in this case restart nsd(8) using its own control tool nsdc(8).

/etc/newsyslog.conf entry:
Code:
### --- NSD logs
/var/log/nsd/nsd.log    bind:wheel      640     366     *       @T00    XCR     /usr/local/etc/nsd/nsd-restart

/usr/local/etc/nsd/nsd-restart contents:
Code:
#!/bin/sh
#
# This script restarts nsd after log rotation by newsyslog(8).
#

/usr/local/sbin/nsdc restart

exit 0

If more information is needed please tell me and I would be gladly to provide it.

Once again, thank you. Cheers and Goodwill.
 
Are the /usr/local/etc/unbound/unbound-reopen-log-file and /usr/local/etc/nsd/nsd-restart scripts marked as executable?
 
Hello SirDice,

Thank you for taking your time for answering my question. Yes they both are.
Code:
root|host /usr/local/etc/unbound # ls -al unbound-reopen-log-file                       
-rwxr-xr-x  1 root  wheel  178 May 24 11:51 unbound-reopen-log-file

Code:
root|host /usr/local/etc/nsd # ls -al nsd-restart
-rwxr-xr-x  1 root  wheel  115 May 23 10:24 nsd-restart

I don't think it has anything to do with the newsyslog(8) problem mentioned in the previous post but it is worth mentioning that nsd(8) is installed and configured inside a jail.

Are there other tools that I can use to track/debug the newsyslog(8) command in real time to see what it's doing behind the scenes? Tools beside ktrace(1).

Thank you. Cheers and Goodwill.
 
I had this same problem. The above revision didn't work for me. I opened the following bug report and worked with Mark from the BSD team on this.

http://www.freebsd.org/cgi/query-pr.cgi?pr=175330

The patch supplied in that pr fixed the problem I was having.

I understand this is quite a late followup but wanted to update this thread with my findings so that others, if they have this problem, can potentially get some closure.
 
I experienced the same issues mentioned earlier in this thread. I solved it by utilizing the below configuration:


When Unbound first creates the log file /usr/local/unbound/unbound.conf, the file permissions are as follows:

Code:
-rw-r-----  1 unbound  wheel     6177 Aug  2 15:00 unbound.log


Additionally, enclosed is the content of my /etc/newsyslog.conf entry:

Code:
/usr/local/etc/unbound/unbound.log  unbound:wheel     640   7     *    @T15  JBR   /usr/local/etc/unbound/unbound-log-reopen


Here is the content of the script /usr/local/etc/unbound/unbound-log-reopen:

Code:
#
#!/bin/sh
#This script restarts unbound after log rotation by newsyslog(8).
#

/usr/local/sbin/unbound-control -q log_reopen

exit 0


The file permissions of /usr/local/etc/unbound/unbound-log-reopen:

Code:
-rwxr--r--  1 unbound  wheel      135 Aug  2 09:28 unbound-log-reopen*


This configuration works fine in my environment (FreeBSD 10) and allows Unbound to continue to run without having the service restarted in order to rotate the log files. The main issue is the correct and consistent file permissions on the associated files.

Note: Unbound used in this post was installed from the FreeBSD Ports Collection and not the Unbound found in the Base FreeBSD System.


Regards,

Scott - w5plt
 
Back
Top