[Dnsmasq-discuss] log rotation again...

Carlos Carvalho carlos at fisica.ufpr.br
Tue May 1 16:35:11 BST 2007


It seems this has been sent this only to me but since Simon asks
everybody (at the end) I'm answering to the list.

Simon Kelley (simon at thekelleys.org.uk) wrote on 1 May 2007 11:38:
 >Carlos Carvalho wrote:
 >
 >> The problem with copytruncate is that it may cause some entries to be
 >> lost, so it should be used as a last resort only.
 >> 
 >> Maybe in a next release this possibility could be included... :-)
 >
 >I re-read "man logrotate" and the crucial bit seems to be this:
 >
 >create mode owner group
 >              Immediately  after rotation (before the postrotate
 >              script is run) the log file is created  (with  the
 >              same  name  as  the  log file just rotated).  mode
 >              specifies the mode for the log file in octal  (the
 >              same  as  chmod(2)), owner specifies the user name
 >              who will own the log file, and group specifies the
 >              group  the log file will belong to. Any of the log
 >              file attributes may  be  omitted,  in  which  case
 >              those  attributes  for  the  new file will use the
 >              same values as the original log file for the omit-
 >              ted  attributes. This option can be disabled using
 >              the nocreate option.
 >
 >So that's fine: just do
 >
 >create 640 nobody root
 >postrotate kill -USR2 ‘cat /var/run/dnsmasq.pid‘
 >
 >or
 >
 >create 640 dnsmasq root
 >postrotate kill -USR2 ‘cat /var/run/dnsmasq.pid‘
 >
 >and logrotate will make a suitable new file

Exactly, that's what I had in mind. The savelog script in Debian can
also do it.

 >Adding the signal is slightly non-trivial (there's a whole set of
 >processes which might have the log file open) but it should be possible.

I trust you :-)

 >Does anybody have an opinion on the best signal to use , given that
 >SIGHUP is already taken?

I'd go with USR2 as you suggested. HUP can also do it in addition to
what it already does, like some other daemons do.

One thing that is different in dnsmasq compared to many other daemons
is that HUP does not re-read the main config, so it's not a full
reload. I guess that's because dnsmasq has a lot of state to preserve
(other processes, cache, leases). Is this correct?



More information about the Dnsmasq-discuss mailing list