Hi g1, On Thu, Aug 21, 2025 at 02:52:50PM +0200, g1 wrote: > What about imitating the /etc/logrotate.d/wtmp file shipped by logrotate?
I have been mulling on this for a while in case any reasons came up why this was a bad idea. I think it's the best one. Initially I looked for a solution around 'wtmpdb rotate' since it must have been written for a reason, and was already used in the Debian package, but I just don't see that it helps. In fact it can have some pathological results: if you get a future time in there it doesn't get rotated and then later events get matched against it. (See: <https://github.com/thkukuk/wtmpdb/issues/28>.) I removed rotation entirely because without pruning it seemed to have no value - only making it harder to query the past. And I didn't replace it with anything because we were in the trixie freeze and I thought it better to have no rotation than introducing something that turned out to be worse than nothing. On Fri, Aug 22, 2025 at 09:17:29AM +0200, g1 wrote: > /var/lib/wtmpdb/wtmp.db { > missingok > monthly Personally I'd go with yearly - which is probably already the case de facto due to the minsize option. On the other hand, this is closer to what was before with wtmp. There was a suggestion that there might be regulatory reasons to limit the data collected but I find this unconvincing, as in the settings where they MIGHT apply (shell account servers selling to non-business users in specific countries?) the administrator will need to make system-wide decisions on a number of logging matters and us being arbitrarily more or less conservative has no guarantee of falling on the right side of the user's particular cut-off point! > nocreate > minsize 1M > nocompress > rotate 4 > olddir /var/log I, too, think the rotated logs belong in /var/log - feels like an FHS violation to keep them in the /var/lib where they could be lost unintentionally (or incompetently - I just deleted by wtmp.db while testing out things related to your suggestion!) However, when I sounded out some other people on log rotation there was a suggestion that mixing the locations was bad. I'm still open to it, though! > } There is also the question of the post-rotation step: 'last' will report an error on a non-existent file: should we seed the next one with 'wtmpdb boot'? $ wtmpdb boot -f foo Boot time too far in the past, using current time: Boot time: Fri Aug 22 18:51:05 2025 Current time: Fri Aug 22 19:06:46 2025 $ last -f foo s-reboot system boot 6.12.38+deb13-am Fri Aug 22 19:06 - still running foo begins Fri Aug 22 19:06:46 2025 $ last -f bar open_database_ro: Cannot open database (bar): unable to open database file > -- System Information: > Debian Release: 12.11 > APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, > 'oldstable') > APT prefers oldstable-updates OOI, Did you build wtmpdb for bookworm or were you mid-upgrade? > Architecture: amd64 (x86_64) > > Kernel: Linux 6.1.0-38-amd64 (SMP w/12 CPU threads; PREEMPT) > Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set > Shell: /bin/sh linked to /usr/bin/dash > Init: sysvinit (via /sbin/init) :-) > LSM: AppArmor: enabled Thanks for your input on this issue. Do share any further thoughts you have! Now might be a good time to get this change in as it leaves plenty of chance for users to report issues before forky is released. Andrew
