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.

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)

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.

Greets,
Dirk =)


-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 6.12.20-amd64 (SMP w/20 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages wtmpdb depends on:
ii init-system-helpers 1.68
ii libaudit1 1:4.0.2-2+b2
ii libc6 2.41-6
ii libsystemd0 257.4-3
ii libwtmpdb0 0.72.0-1

Versions of packages wtmpdb recommends:
ii libpam-wtmpdb 0.72.0-1

wtmpdb suggests no packages.

-- no debconf information

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)