Date: Tue, 8 Jul 2003 12:27:26 +0300 From: Jim Xochellis <dxoch@escape.gr> To: Garance A Drosihn <drosih@rpi.edu> Cc: freebsd-questions@freebsd.org Subject: Re: About newsyslog behavior Message-ID: <633C4AA6-B126-11D7-B276-003065C4E486@escape.gr> In-Reply-To: <p0521064cbb2a4f01a72e@[128.113.24.47]>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Garance, Hi list, I spend some time thinking about all this newsyslog stuff and I am starting to feel that maybe I am making too much noise for minor problems. After all disk space is very cheap and turning over the logs is not something that we have to do very often. In many cases we can even do it by hand! Nevertheless, I will try to explain my thoughts in a better way this time. On Friday, July 4, 2003, at 12:44 AM, Garance A Drosihn wrote: > At 12:08 PM +0300 7/2/03, Jim Xochellis wrote: > [...] >> I have confirmed that newsyslog actually creates a new >> log file (instead of copying it and then disposing its >> contents) by reading the source of the newsyslog.c file > > Yes, and that doen because it is the safest and most > reliable way for it to rotate a logfile without any > hitting any race-conditions. In fact newsyslog works OK when the process that creates the log is not a server for other users / computers and reacts correctly to SIGHUP. I have use it my self to turn over the log of "ipmon" (IPF firewall) and everything works great. But sending SIGHUP to a file server (or to an other kind of server perhaps) is something that I want to avoid even if SIGHUP re-opens correctly the logs. AFAIK when a file server (i.e. Netatalk) receives an SIGHUP it closes (gracefully I admit) the connections to its clients. And this happens just because log file is turned over by newsyslog! (too much IMHO) One possible way to reduce these side-effects is to schedule newsyslog to turn over the logs after midnight and avoid rush hours (I am doing that at the moment). This is a practical solution that really helps but its also incomplete. I realize that I am not talking about a major problem here. But I am proposing a solution (to a non major problem) that is very easy to implement. See bellow about the possibility to have race-conditions in a server with many processes. [...] > >> Isn't it feasible to dispose the contents of the old log >> file instead of creating a new one? Anything that I am >> missing here? (giving the fact that I am not a unix guru, >> only a C programmer) > > If the program does not have some way to REALLY re-open the > log file, then the file-pointer might also be pointing to a > specific point in the file. Let's say it is at byte 125000 > into the file. You empty the file. The next time the > program writes to the log file, it will write to byte 125001 > (depending on how the program is written). Some programs > may work with this strategy, but others will not. > I admit that disposing the contents of the old log file instead of creating a new one could be dangerous in some cases and should NOT be the default behavior of newsyslog. I am talking about a per-file basis option and nothing more. I believe that this option can be both useful and harmless when used with most servers. Useful: Because we should always try our best not to interrupt the server-client connection (Which actually happens when sending SIGHUP) Harmless: Because I am talking about typical serves (Netatalk, samba, apache...) that are using many processes which are all writing in the same log file. In these cases we should not expect any race-conditions in the log files because the servers have already solved these problems in order to implement logging for their own processes. (OK there is still a case (in theory) that the processes are handling the logging via interprocess communication instead of re-opening / flushing the logs files locally. IMHO this would be impractical and is not really possible to have such a case in a real world situation! Am I right here?) [...] Best Regards Jim Xochellis
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?633C4AA6-B126-11D7-B276-003065C4E486>