[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