Date: Fri, 14 Feb 2003 15:30:51 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Gordon Tetlow <gordont@gnf.org> Cc: Garance A Drosihn <drosih@rpi.edu>, arch@FreeBSD.ORG Subject: Re: syslog.conf syntax change (multiple program/host specifications) Message-ID: <3E4D7C2B.DDFC9DBE@mindspring.com> References: <20030210114930.GB90800@melusine.cuivre.fr.eu.org> <20030213174531.GZ83215@roark.gnf.org> <20030213184309.GA53098@melusine.cuivre.fr.eu.org> <200302141100.23529.wes@softweyr.com> <p05200f15ba72fb31e177@[128.113.24.47]> <20030214220145.GM83215@roark.gnf.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Gordon Tetlow wrote: > From newsyslog(8): > > -F Force newsyslog to trim the logs, even if the trim conditions > have not been met. This option is useful for diagnosing system > problems by providing you with fresh logs that contain only the > problems. Not really useful. For example, we had a system where cron would occasionally die, because it was FreeBSD 3.x based, and there was a bug in the copy-on-write code in the FreeBSD VM for pages that were mapped COW and read-only. The problem showed up occasionally, when Vixie cron would modify the contents of the pwent struct, thus assuming that the values pointed to by the struct elements were static data areas, rather than pointers into a Berkeley db record that was mmap'ed with these attributes out of the passwd db file, instead. The result was that it would write a page of password db file entry over top of the cron tab, which was open at the time. So then cron would die. The reason this is interesting for a discussion of newsyslog is that newsyslog was run from cron. The upshot of this is that you'd get a box that seemed OK, but on which newsyslog would not be run for a very long time. This resulted in very large log files. The "fix", which wasn't one, was to regenerate the crontab from a template and stored data, shen you rebooted the system. Then you would reboot, the crontab would be regenerated, and cron would run normally again, running newsyslog. Only newsyslog is stupid. No matter what options you gave it, the first thing it would do is the moral equivalent of -F. So instead of a 60M Samba log file "/var/log/samba", you ended up with a "/var/log/samba.1" that was 60M, and a "/var/log/samba" that was empty. As you can see, this leaves /var full, because it did not "rewrite history", and break the log file up into pieces the size of the retained log, according to newsyslog's config, *as if newsyslog had run normally*. E.g., if I keep 40K per log for 5 versions, then: old new expected (rewrite) samba 60M 0K 0K samba.1 41K 60M 40K samba.2 40K 41K 40K samba.3 43K 40K 40K samba.4 47K 43K 40K samba.5 42K 47K 40K total: 60.3M 60.2M 120K The result was a machine that turns into a doorstop, and then stays a doorstop. I would really object to rolling this same thing into syslog, without fixing this first. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E4D7C2B.DDFC9DBE>