Control: tags -1 - moreinfo + confirmed Control: forwarded -1 https://github.com/thkukuk/wtmpdb/pull/40
On Mon, Apr 07, 2025 at 01:42:37AM +0100, Andrew Bower wrote: > On Sat, Apr 05, 2025 at 05:43:53AM +0200, Dirk Lehmann wrote: > > 2. The [shutdown] in the example above was from > > > > [shutdown] 05:01 - 05:04, followed by a > > [reboot] at 05:04 - still running > > > > but this [shutdown] was ordered before > > > > [reboot] at 01:27 - 05:01 > > > > which make less sense. The output of example above should look like > > > > root pts/0 Sat Apr 5 05:09 - still > > logged in > > dirk tty7 :0 Sat Apr 5 05:05 - still > > logged in > > lightdm tty7 :0 Sat Apr 5 05:04 - 05:05 > > (00:00) > > reboot system boot 6.12.20-amd64 Sat Apr 5 05:04 - still > > running > > shutdown system down 6.12.20-amd64 Sat Apr 5 05:01 - 05:04 > > (00:03) > > root pts/4 Sat Apr 5 04:16 - 04:16 > > (00:00) > > [...] > > lightdm tty7 :0 Sat Apr 5 01:27 - 01:27 > > (00:00) > > reboot system boot 6.12.20-amd64 Sat Apr 5 01:27 - 05:01 > > (03:33) > > new> <older shutdown> Sat Apr 5 01:26 - 01:27 > > (00:00) > > root pts/0 Sat Apr 5 01:26 - 01:26 > > (00:00) > > I am inclined to agree that this is wrong. Comparing the output with > classic last on a proper wtmp log for identical reboot events I see that > this is a regression with wtmpdb. Note that wtmpdb internally logs boot > and shutdown events as a pair, unlike in the utmp format where they are > separate events. I have proposed https://github.com/thkukuk/wtmpdb/pull/40 upstream to fix this. > > 3. With respect to bug #1102101 (subtract 1h) > > > > * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1102101 > > > > the following command should output at least one [shutdown] line > > > > $> last -x -s '2025-04-05 03:00:00' > > root pts/0 Sat Apr 5 05:09 - still > > logged in > > dirk tty7 :0 Sat Apr 5 05:05 - still > > logged in > > lightdm tty7 :0 Sat Apr 5 05:04 - 05:05 > > (00:00) > > reboot system boot 6.12.20-amd64 Sat Apr 5 05:04 - still > > running > > root pts/4 Sat Apr 5 04:16 - 04:16 > > (00:00) > > > > wtmpdb begins Fri Apr 4 19:01:21 2025 > > > > the `[shutdown] 05:01 - 05:04 (00:03)` is missing. > > I would rather not look into this particular case while both #1102101 > and your issue 2 above are unfixed to avoid wasted effort. Does it seem > likely to you that this interaction is covered by these? I believe symptom 3 is also a bug, but not a very important one - we should perhaps accept this as a limitation, that the time filtering is done on the boot time and ignores the shutdown time. It is probably fixable but it would take a bit more surgery upstream. Andrew
