On Fri, Aug 22, 2025 at 07:09:07PM +0100, Andrew Bower wrote:
> 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!
I agree with you that the current combination of "rotate", "monthly" and
"minsize" parameters can yield very different (and unpredictable) rotation
intervals depending on system use: probably the best course of action is
to provide a minimal viable configuration to prevent infinite growth, and
let system administrators adapt it to their needs (technical or legal).
In fact, the minsize can be misleading, since the wtmp db (space-efficient
sqlite) grows much more slowly than the legacy wtmp file (fixed format
records).
>
> > 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!
I'm wondering what happens if /var/lib/wtmpdb/wtmp.db is replaced with
a symlink to /var/log/wtmp.db. If it works smoothly, then "what happens
in /var/log stays in /var/log" and /var/lib gets rid of a log file
in disguise.
>
> > }
>
> 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
Personally, I'd prefer to get an error instead of a "synthetic" boot event.
As an alternative, wtmpdb could ship a wtmp-empty.db file (an empty sqlite
db with the correct schema), and replace the removed wtmp.db with that
file in the postrotate action of the logrotate snippet.
>
> > -- 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?
"Mid-upgrade": migrated some machines to trixie, but my PC is still
bookworm, and I forgot to delete the info that reportbug appends
automatically.
>
> > 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)
>
> :-)
>
Argh... reportbug ratted on me.
> > 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
Best regards
g.b.
