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
signature.asc
Description: PGP signature
