Package: wtmpdb
Version: 0.72.0-1
Severity: normal

Dear Maintainer,

for the command-line argument `last -p <TIME>` there are existing at
least 4 issues:

1. last -p now

Works on the older util-linux version and shows all current
"still ..." active sessions. But the wtmpdb version, which I am
reporting here outputs

$> last -p now
Invalid time value 'now'

2. last -p <TIME>

The <TIME> is neither interpreted as UTC nor as local time. My
current system is using time zone (+0100) plus summer time, which
results in (CEST, +0200).

$> timedatectl
Local time: Sat 2025-04-05 04:08:45 CEST
Universal time: Sat 2025-04-05 02:08:45 UTC
RTC time: Sat 2025-04-05 02:08:45
Time zone: Europe/Berlin (CEST, +0200)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no

In the following example a su(1) session starts at 03:39 local
time. To request it using -p argument I need to substract 1h,
i.e. 02:39. Don't know why 1h.

$> wtmpdb last -p '2025-04-05 02:40:00'
root pts/0 Sat Apr 5 03:39 - 03:47 (00:07)
dirk tty7 :0 Sat Apr 5 01:48 - still logged in
reboot system boot 6.12.20-amd64 Sat Apr 5 01:27 - still running

wtmpdb begins Fri Apr 4 19:01:21 2025

$> wtmpdb last -p '2025-04-05 02:38:00'
dirk tty7 :0 Sat Apr 5 01:48 - still logged in
reboot system boot 6.12.20-amd64 Sat Apr 5 01:27 - still running

wtmpdb begins Fri Apr 4 19:01:21 2025

3. last -p <RFC 3339 TIME>

Wishlist: Would be nice if <TIME> accepts fully the RFC 3339
format. Then the following example should work, which is
equivalent to `last -p now`:

$> last -p "$(date --rfc-3339=seconds)"
Invalid time value '2025-04-05 04:26:47+02:00'

4. last -p

Wishlist: Would be nice to make the <TIME> optional, like
[<TIME>]. This should be equivalent to `last -p now`.

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 confirmed upstream

Hi Dirk,

Thanks for this. The four issues here need to be dealt with separately:

On Sat, Apr 05, 2025 at 04:38:17AM +0200, Dirk Lehmann wrote:

for the command-line argument `last -p <TIME>` there are existing at
least 4 issues:

1. last -p now

Works on the older util-linux version and shows all current
"still ..." active sessions. But the wtmpdb version, which I am
reporting here outputs

$> last -p now
Invalid time value 'now'

Agreed that this is a defect: I consider any feature miss in wtmpdb that
was available with the classic tools to be a bug unless it does not fit
within the wtmpdb idiom.

The remedy here is for the wtmpdb to accept a richer range of time
format specifications. I suggest it should as a minimum accept
everything listed in the util-linux last(1) man page before it was
withdrawn from Debian:

https://manpages.debian.org/bookworm/util-linux/last.1.en.html#TIME_FORMATS

2. last -p <TIME>

The <TIME> is neither interpreted as UTC nor as local time. My
current system is using time zone (+0100) plus summer time, which
results in (CEST, +0200).

$> timedatectl
Local time: Sat 2025-04-05 04:08:45 CEST
Universal time: Sat 2025-04-05 02:08:45 UTC
RTC time: Sat 2025-04-05 02:08:45
Time zone: Europe/Berlin (CEST, +0200)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no

In the following example a su(1) session starts at 03:39 local
time. To request it using -p argument I need to substract 1h,
i.e. 02:39. Don't know why 1h.

$> wtmpdb last -p '2025-04-05 02:40:00'
root pts/0 Sat Apr 5 03:39 - 03:47 (00:07)
dirk tty7 :0 Sat Apr 5 01:48 - still logged in
reboot system boot 6.12.20-amd64 Sat Apr 5 01:27 - still running

wtmpdb begins Fri Apr 4 19:01:21 2025

$> wtmpdb last -p '2025-04-05 02:38:00'
dirk tty7 :0 Sat Apr 5 01:48 - still logged in
reboot system boot 6.12.20-amd64 Sat Apr 5 01:27 - still running

wtmpdb begins Fri Apr 4 19:01:21 2025

This looks similar to an issue where the DST field in the structure used
by strptime() was uninitialised, resulting in erratic behaviour:

https://bugs.launchpad.net/ubuntu/+source/wtmpdb/+bug/2088387

but in this case it is predictable behaviour and the structure is
initialised. However, this points to a wider issue of the timezone being ignored, which it is not in the classic last implementation (I just
checked). So there is an upstream bug whereby the requested time is not converted from local time. That means there are two bugs here although
it might be that one fix fixes both.

3. last -p <RFC 3339 TIME>

Wishlist: Would be nice if <TIME> accepts fully the RFC 3339
format. Then the following example should work, which is
equivalent to `last -p now`:

$> last -p "$(date --rfc-3339=seconds)"
Invalid time value '2025-04-05 04:26:47+02:00'

A nice idea for the upstream wishlist. I think ISO-8601 would be a nice
option, too.

4. last -p

Wishlist: Would be nice to make the <TIME> optional, like
[<TIME>]. This should be equivalent to `last -p now`.

I don't think this can be done because if you change whether the
argument is optional or not you affect how subsequent options are
interpreted. Do you know of another implementation supports this? The
classic last command in Debian doesn't. I agree it would be nice,
though!

It might be worth interacting with the upstream bug tracker for action
on some of these as they may need negotiation.

Andrew

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEMKYZL6LI55lncG11uqgO2W94h+kFAmfy5qwACgkQuqgO2W94 h+mJbA//fDmrTHWjiSOc8KKkKonXsuPT8bmSed0lM3+NB64SAZeDdLz9AotV8kLj tgJf68IWiy2iJjMiYbV7wilH6FcnQa0opsVVE0sOGhY0ubl1oTVwOpppoa1Z8qdN ws2w1DAbpSpC1e7HpS22sASquhP9TDAwb5EfkmkFGUjSmvjI5bGiQzZU54+6eFkU b0Z0A+ubF0hVhpHdOUfp4pz8LqNZaRJcXeuNFt5WbPce/ZCnhoEIGtxbs07lXdN5 3eKDA1hrSAL838fKAz2ppNCMkrqmlddf1W5dWHyoqYxjyq9iNJuxj6fz3bjzd+87 b7oMoZcglGjveYmM94AYuvLbJA2ESj3fI8P7he6tB1kWKxiBMnssYtZmqLyTJ++Z 63D4VNdseuDwRtBaCSBPI1dKNaBkl6iVsmqtA95GrmFKAxeBGNFbS4mMdl5aWGkt 2/+9rgGILhqO5e8Hk7zl90Dfs0HGEzspgFztEo2yc8kIjWYEn25WXTC0bEIC5yZI F8/vWdtwLw5FSvRwM3ttHsocnIyhyfIb8cCNVXFEkzTREJQOLHv56GEVPOm7kE2s 3h+49jdykW5W/tqju2ZrIuiMMMnY8Vy5YL+FpDdfIYOkN11UdvtHnxZU/5rJzreK uQgxXL2W4hqbDBUZ/AlVSkdFIk4uvw/AaBkVQw/GhMJM0/+wQvo=
=I/Ff
-----END PGP SIGNATURE-----

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

Control: tags -1 patch
Control: forwarded -1 https://github.com/thkukuk/wtmpdb/issues/33

Hi Dirk,

A quick update:

On Sun, Apr 06, 2025 at 09:40:17PM +0100, Andrew Bower wrote:

Thanks for this. The four issues here need to be dealt with separately:

On Sat, Apr 05, 2025 at 04:38:17AM +0200, Dirk Lehmann wrote:

for the command-line argument `last -p <TIME>` there are existing at
least 4 issues:

1. last -p now

Works on the older util-linux version and shows all current
"still ..." active sessions. But the wtmpdb version, which I am
reporting here outputs

$> last -p now
Invalid time value 'now'

Agreed that this is a defect: I consider any feature miss in wtmpdb that
was available with the classic tools to be a bug unless it does not fit within the wtmpdb idiom.

The remedy here is for the wtmpdb to accept a richer range of time
format specifications. I suggest it should as a minimum accept
everything listed in the util-linux last(1) man page before it was
withdrawn from Debian:

https://manpages.debian.org/bookworm/util-linux/last.1.en.html#TIME_FORMATS

Thank you for forwarding this to: https://github.com/thkukuk/wtmpdb/issues/32
I have proposed a fix at: https://github.com/thkukuk/wtmpdb/pull/36

2. last -p <TIME>

The <TIME> is neither interpreted as UTC nor as local time. My
current system is using time zone (+0100) plus summer time, which
results in (CEST, +0200).

$> timedatectl
Local time: Sat 2025-04-05 04:08:45 CEST
Universal time: Sat 2025-04-05 02:08:45 UTC
RTC time: Sat 2025-04-05 02:08:45
Time zone: Europe/Berlin (CEST, +0200)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no

In the following example a su(1) session starts at 03:39 local
time. To request it using -p argument I need to substract 1h,
i.e. 02:39. Don't know why 1h.

$> wtmpdb last -p '2025-04-05 02:40:00'
root pts/0 Sat Apr 5 03:39 - 03:47 (00:07)
dirk tty7 :0 Sat Apr 5 01:48 - still logged in
reboot system boot 6.12.20-amd64 Sat Apr 5 01:27 - still running

wtmpdb begins Fri Apr 4 19:01:21 2025

$> wtmpdb last -p '2025-04-05 02:38:00'
dirk tty7 :0 Sat Apr 5 01:48 - still logged in
reboot system boot 6.12.20-amd64 Sat Apr 5 01:27 - still running

wtmpdb begins Fri Apr 4 19:01:21 2025

This looks similar to an issue where the DST field in the structure used
by strptime() was uninitialised, resulting in erratic behaviour:

https://bugs.launchpad.net/ubuntu/+source/wtmpdb/+bug/2088387

but in this case it is predictable behaviour and the structure is initialised.

Thank you for forwarding this to: https://github.com/thkukuk/wtmpdb/issues/33
I have proposed a fix at: https://github.com/thkukuk/wtmpdb/pull/31

However, this would be superseded by the fix for your issue 1, if
accepted.

However, this points to a wider issue of the timezone being
ignored, which it is not in the classic last implementation (I just
checked). So there is an upstream bug whereby the requested time is not converted from local time. That means there are two bugs here although
it might be that one fix fixes both.

I might have got the above wrong, it looks like wtmpdb does consider the timezone after all. But I raised a question on my PR which might help us
get closer to understanding if there might be anything in it.

3. last -p <RFC 3339 TIME>

Wishlist: Would be nice if <TIME> accepts fully the RFC 3339
format. Then the following example should work, which is
equivalent to `last -p now`:

$> last -p "$(date --rfc-3339=seconds)"
Invalid time value '2025-04-05 04:26:47+02:00'

A nice idea for the upstream wishlist. I think ISO-8601 would be a nice option, too.

Thank you for forwarding this to: https://github.com/thkukuk/wtmpdb/issues/34 This will be very easy to add if my proposed fix for issue 1 is accepted.

4. last -p

Wishlist: Would be nice to make the <TIME> optional, like
[<TIME>]. This should be equivalent to `last -p now`.

I don't think this can be done because if you change whether the
argument is optional or not you affect how subsequent options are interpreted. Do you know of another implementation supports this? The
classic last command in Debian doesn't. I agree it would be nice,
though!

Thank you for forwarding this to: https://github.com/thkukuk/wtmpdb/issues/35

As I said, I don't think this will be actionable!

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