Control: tags -1 moreinfo upstream Hi Dirk,
Thanks for these reports! On Sat, Apr 05, 2025 at 05:43:53AM +0200, Dirk Lehmann wrote: > Package: wtmpdb > Version: 0.72.0-1 > Severity: normal > > Dear Maintainer, > > here an `last -x` example output > > ``` > $> wtmpdb last -x -n20 > 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) > [...] > 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) > shutdown system down 6.12.20-amd64 Sat Apr 5 05:01 - 05:04 (00:03) > root pts/0 Sat Apr 5 01:26 - 01:26 (00:00) > > wtmpdb begins Sat Apr 5 01:26:34 2025 > ``` > > Here are 3 issues: > > 1. Whishlist: For the first column it should be renamed > > shutdown -> [shutdown] or <shutdown> > reboot -> [reboot] or <reboot> > > to make clear that these are builtin tokens, and not real > usernames. The classic 'last' tool does not mark these tokens especially and so far as I know, never has, so I don't think wtmpdb needs to. Do you know any other 'last' implementations that do this? I can understand why you would want this but I think you would need to argue the case for this upstream. I am inclined to consider this aspect of your bug 'wontfix' from a Debian perspective. > 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. > 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? Andrew
