Karl M. Hegbloom wrote: > I'm looking at the source to `logrotate'. It opens the log file, and > then creates a new file, and does a read/write loop to copy the log > file over to the new one, then uses `ftrunctate' to truncate the log > file.
Pardon me while I gag. > Tell me if I'm wrong... but if the `logrotate' process runs out of > time, a process switch happens, (or just happens at the same time, on > an SMP box), then `syslogd' runs and writes to the file, right after > the copy, but before the truncate, won't there be data loss? Yes, it's a race. > I thought what you're supposed to do is `rename(3)' the log file, > since `rename(3)' is atomic, then create a new file with the original > name, and then HUP the daemon, which MUST have a signal handler for > SIGHUP that flags it to close the file descriptor on that logfile, > then reopen it under the same name. Or just force a complete restart of the daemon if it doesn't support that, yes. > Any comments or ideas? There's a proposal in debian-policy that logrotate be made our preferred log rotation method. It's pretty close to becomeing an amendment. I don't think that should happen while logrotate remains so obviously broken. I think we should take a much closer look at the program before going any further with that proposal. -- see shy jo
