On Tue, Aug 26, 2025 at 12:20:26AM +0200, [email protected] wrote: > On Mon, Aug 25, 2025 at 05:08:09PM +0100, Andrew Bower wrote: > > I'm not versed enough in DH to grasp all the details, but what I could > understand looks fine. > > A couple of tiny points, bordering on paranoia: > > - If I'm not wrong, there's a very small window for a race in the > postrotate action, that can be mitigated like this: > > cp /usr/share/wtmpdb/empty.db $1.rnew > chown --reference=$2 $1.rnew > chmod --reference=$2 $1.rnew > ln $1.rnew $1 2>/dev/null || true > rm -f $1.rnew
Yes, I disregarded some races where the outcome was benign but there are others. On the plus side, if we get this right, our solution will also deal with the otherwise elusive bug #1076308. This goes away if we just do logrotate with nocreate and patch wtmpdb not to complain about an empty file. We can stamp the mode after that. Or write the synthetic boot. But we have another race - potential loss of data if wtmpdb writes before we create our own version. We could ideally do with a change to logrotate (maybe we could look into it!) * Add new 'swapnew' option that does your hardlink dance to replace the existing log with a new one as well as renaming the old one atomically. Then we could use this: prerotate install $(stat --printf='-m%a -o%u -g%g' "$1") /usr/share/wtmpdb/empty.db "$1.new" endscript and swapnew would make use it instead of creating an empty file. > - After reviewing the logrotate manpage, I'm a little uncomfortable > with this sentence in the olddir description: "The directory must be > on the same physical device as the log file being rotated, unless > copy, copytruncate or renamecopy option is used". > > What happens if /var/lib/wtmpdb and /var/log belong to distinct > filesystems? > > Maybe it suffices to add "renamecopy" to prevent any possible problem. Yes, renamecopy looks like it solves the problem except that we could still lose data if wtmpdb was accessing the file and for some reason very slow about it - the copy might happen in an unsafe state. Ideally I think we could do with a variant on this in logrotate to benefit when the directories are on the same mount: renamecopyunlesssamedevice well... I'm sure the logrotate upstream maintainers would have an opinion on the name! :-D
