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!
