Hello Andrew =) On 4/6/25 10:40 PM, Andrew Bower wrote:
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 nowWorks 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
I have reported it to upstream BTS at * https://github.com/thkukuk/wtmpdb/issues/32
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 2025This 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
I agree with you. I have reported it to upstream BTS at * https://github.com/thkukuk/wtmpdb/issues/33
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.
Great! I have reported it upstream at * https://github.com/thkukuk/wtmpdb/issues/34
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!
No, I cannot find any other implementation with that feature. I told it in the mailing list, and I remember that I see it in an Unix tutorial. But currently I cannot rediscover it.
It might be worth interacting with the upstream bug tracker for action on some of these as they may need negotiation.
I have reported it to upstream BTS at * https://github.com/thkukuk/wtmpdb/issues/35 Greets, Dirk =)
OpenPGP_signature.asc
Description: OpenPGP digital signature
