64-bit time_t and __WORDSIZE_TIME64_COMPAT32

64-bit time_t and __WORDSIZE_TIME64_COMPAT32

[Thorsten Kukuk]

Hi,

Currently on 64bit architectures like x86-64 we define 
__WORDSIZE_TIME64_COMPAT32 as 1, which leads to a 32bit time_t in utmp,
wtmp, lastlog and similar files.

This leads to the problem, that utmp, wtmp and lastlog stops working
in 2038 even if you have a pure 64bit system. 

Since I couldn't found anything about this, was it ever discussed or is
there any plan how to handle this?

Looking at my system there are much more systems using this interface
than I thought, so my first idea of just deprecating this interface is
no solution.

I think the only solution would be additional functions like for other
32bit time_t functions and use symbol versioning for it?

  Thorsten

-- 
Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies
SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany
Managing Director: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman
(HRB 36809, AG Nürnberg)

Re: 64-bit time_t and __WORDSIZE_TIME64_COMPAT32

[Andreas Schwab]

On Feb 08 2023, Thorsten Kukuk via Libc-alpha wrote:

> I think the only solution would be additional functions like for other
> 32bit time_t functions and use symbol versioning for it?

That won't work as is because struct lastlog and struct utmp describe
the layout of the lastlog and utmp/wtmp files.  That's the whole reason
for the existence of the __WORDSIZE_TIME64_COMPAT32 knob.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: 64-bit time_t and __WORDSIZE_TIME64_COMPAT32

[Thorsten Kukuk]

On Wed, Feb 08, Andreas Schwab wrote:

> On Feb 08 2023, Thorsten Kukuk via Libc-alpha wrote:
> 
> > I think the only solution would be additional functions like for other
> > 32bit time_t functions and use symbol versioning for it?
> 
> That won't work as is because struct lastlog and struct utmp describe
> the layout of the lastlog and utmp/wtmp files.  That's the whole reason
> for the existence of the __WORDSIZE_TIME64_COMPAT32 knob.

That's solveable with e.g. creating a new name for them (.e.g
/run/utmp64 instead of /run/utmp)

  Thorsten

-- 
Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies
SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany
Managing Director: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman
(HRB 36809, AG Nürnberg)

Re: 64-bit time_t and __WORDSIZE_TIME64_COMPAT32

[Andreas Schwab]

On Feb 08 2023, Thorsten Kukuk via Libc-alpha wrote:

> That's solveable with e.g. creating a new name for them (.e.g
> /run/utmp64 instead of /run/utmp)

That needs to be coordinated with all consumers and producers of those
files.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: 64-bit time_t and __WORDSIZE_TIME64_COMPAT32

[Thorsten Kukuk]

On Wed, Feb 08, Andreas Schwab wrote:

> On Feb 08 2023, Thorsten Kukuk via Libc-alpha wrote:
> 
> > That's solveable with e.g. creating a new name for them (.e.g
> > /run/utmp64 instead of /run/utmp)
> 
> That needs to be coordinated with all consumers and producers of those
> files.

If the consumers and producers uses the glibc API for this, you just
need to recompile them with the new interface. No need to change any 
paths in the source code, the fitting ones comes with glibc, too.

If they declare utmp and the file locations at their own, you need to
modify them anyways. And if you do that, you can change them to use
the official glibc API and not their own written one.

But at least it's a solution to solve the Y2038 problem in glibc for
64bit architectures like x86-64.

And for utmp you can ignore the on disk file format anyways, at it will
not survive a reboot. Not sure about lastlog, wtmp is a problem.

  Thorsten

-- 
Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies
SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany
Managing Director: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman
(HRB 36809, AG Nürnberg)

Re: 64-bit time_t and __WORDSIZE_TIME64_COMPAT32

[Andreas Schwab]

On Feb 08 2023, Thorsten Kukuk via Libc-alpha wrote:

> If they declare utmp and the file locations at their own, you need to
> modify them anyways. And if you do that, you can change them to use
> the official glibc API and not their own written one.

See utmpname.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: 64-bit time_t and __WORDSIZE_TIME64_COMPAT32

[Thorsten Kukuk]

On Wed, Feb 08, Andreas Schwab wrote:

> On Feb 08 2023, Thorsten Kukuk via Libc-alpha wrote:
> 
> > If they declare utmp and the file locations at their own, you need to
> > modify them anyways. And if you do that, you can change them to use
> > the official glibc API and not their own written one.
> 
> See utmpname.

Correct, see above.
But the good thing is: none of the standart tools accessing utmp
use this function.

The alternative is, that all this code get's their own code to
handle utmp, wtmp and lastlog themself. Would be much more efford to
coordinate this.

  Thorsten

-- 
Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies
SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany
Managing Director: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman
(HRB 36809, AG Nürnberg)

Re: 64-bit time_t and __WORDSIZE_TIME64_COMPAT32

[Adhemerval Zanella Netto]

On 08/02/23 07:38, Thorsten Kukuk via Libc-alpha wrote:
> On Wed, Feb 08, Andreas Schwab wrote:
> 
>> On Feb 08 2023, Thorsten Kukuk via Libc-alpha wrote:
>>
>>> If they declare utmp and the file locations at their own, you need to
>>> modify them anyways. And if you do that, you can change them to use
>>> the official glibc API and not their own written one.
>>
>> See utmpname.
> 
> Correct, see above.
> But the good thing is: none of the standart tools accessing utmp
> use this function.
> 
> The alternative is, that all this code get's their own code to
> handle utmp, wtmp and lastlog themself. Would be much more efford to
> coordinate this.
> 
>   Thorsten
> 


I proposed a fix for the utmp/utmpx/lastlog interface on the initial 64 bit
time_t support [1] (patch 16 to 22) and Florian suggested to just deprecate
the interface altogether (the DoS BZ#24492 essentially requires rewrite to
use an external daemon, which is not what we want).

My proposal was essentially to create new path and use 64-bit time_t field,
along with some internal conversions if the old path is used.  I ended drop
this part from 64 bit interface because it is a legacy interface and it 
would most likely generate some breakage.

[1] https://sourceware.org/pipermail/libc-alpha/2021-March/123341.html

Re: 64-bit time_t and __WORDSIZE_TIME64_COMPAT32

[Thorsten Kukuk]

On Wed, Feb 08, Adhemerval Zanella Netto via Libc-alpha wrote:

> I proposed a fix for the utmp/utmpx/lastlog interface on the initial 64 bit
> time_t support [1] (patch 16 to 22) and Florian suggested to just deprecate
> the interface altogether (the DoS BZ#24492 essentially requires rewrite to
> use an external daemon, which is not what we want).
> 
> My proposal was essentially to create new path and use 64-bit time_t field,
> along with some internal conversions if the old path is used.  I ended drop
> this part from 64 bit interface because it is a legacy interface and it 
> would most likely generate some breakage.

Thanks for this informations.

I agree that utmp/wtmp are legacy and started to collect data, which
applications uses utmp/wtmp/btmp/lastlog on a typical openSUSE server
installation:

https://github.com/thkukuk/utmpx/blob/main/Y2038.md

The biggest problem is, there are still quite some tools which modifies
utmp/wtmp directly, so that code needs to be rewriten anyways.

I think we don't lose anything if btmp and lastlog don't exist anymore.
Querying utmp for the runlevel in systemd times is also obsolete.
Statistical data how many users are logged in if you login or if you
call uptime is also only nice to have, nothing more.

So the main consumer of utmp is glibc itself: getlogin()/getlogin_r()
Is there any idea how to replace that, if utmp/wtmp gets deprecated?
That's the only use case for which I don't see an alternate currently.
The musl libc way to use an environment variable is really not safe...

Another real usecase is to find the TTYs for wall and wall alike
messages by tools like shutdown, systemd and similar.

Functions like login()/logout() are only used by openssh. So should be
solveable, too.

  Thorsten


> 
> [1] https://sourceware.org/pipermail/libc-alpha/2021-March/123341.html

-- 
Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies
SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany
Managing Director: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman
(HRB 36809, AG Nürnberg)

Re: 64-bit time_t and __WORDSIZE_TIME64_COMPAT32

[Florian Weimer]

* Thorsten Kukuk via Libc-alpha:

> I think we don't lose anything if btmp and lastlog don't exist anymore.
> Querying utmp for the runlevel in systemd times is also obsolete.
> Statistical data how many users are logged in if you login or if you
> call uptime is also only nice to have, nothing more.

This is something that systemd could do, in a far more reliable fashion
(or the kernel audit subsystem, I assume).

> So the main consumer of utmp is glibc itself: getlogin()/getlogin_r()
> Is there any idea how to replace that, if utmp/wtmp gets deprecated?

We use /proc/self/loginuid already, and try to resolve that UID using
NSS.  We still have fallback to __getutline_r.  I think it would be
really helpful if you could discover why that fallback is used.  I would
have thought it's dead code.

Is it because /proc/self/loginuid is missing, or because NSS fails for
some reason?  If it's about /proc/self/loginuid, maybe we can look at
the owner of /dev/tty instead.

> That's the only use case for which I don't see an alternate currently.
> The musl libc way to use an environment variable is really not safe...

The manual page has strong guidance that getlogin is not to be trusted.
/proc/self/loginuid is probably quite hard to fool, though, but the
fallback code is another matter.

> Another real usecase is to find the TTYs for wall and wall alike
> messages by tools like shutdown, systemd and similar.

Again, this seems to be more in the realm of the init service.

> Functions like login()/logout() are only used by openssh. So should be
> solveable, too.

Also FTP servers.  But we have seen quite a few problems due to account
database updates because the data structure isn't great, and isn't
really suitable to handling PTYs.

Thanks,
Florian

Re: 64-bit time_t and __WORDSIZE_TIME64_COMPAT32

[Thorsten Kukuk]

On Tue, Feb 14, Florian Weimer wrote:

> * Thorsten Kukuk via Libc-alpha:

> > So the main consumer of utmp is glibc itself: getlogin()/getlogin_r()
> > Is there any idea how to replace that, if utmp/wtmp gets deprecated?
> 
> We use /proc/self/loginuid already, and try to resolve that UID using
> NSS.  We still have fallback to __getutline_r.  I think it would be
> really helpful if you could discover why that fallback is used.  I would
> have thought it's dead code.
> 
> Is it because /proc/self/loginuid is missing, or because NSS fails for
> some reason?  If it's about /proc/self/loginuid, maybe we can look at
> the owner of /dev/tty instead.

I made an half-automatic analysis of the binaries and corresponding
source code and it seems I looked at the wrong sysdeps file in the glibc
sources :( I didn't checked at runtime as I never know if I hit the
correct execution path or not.
Sorry, with the current glibc implementation we should be fine, so I
will create bug reports against the projects who implemented their own
getlogin() function based on utmp.

Thanks, I will fix my document.

  Thorsten

-- 
Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies
SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany
Managing Director: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman
(HRB 36809, AG Nürnberg)

Re: 64-bit time_t and __WORDSIZE_TIME64_COMPAT32

[Adhemerval Zanella Netto]

On 14/02/23 06:26, Thorsten Kukuk via Libc-alpha wrote:
> On Tue, Feb 14, Florian Weimer wrote:
> 
>> * Thorsten Kukuk via Libc-alpha:
> 
>>> So the main consumer of utmp is glibc itself: getlogin()/getlogin_r()
>>> Is there any idea how to replace that, if utmp/wtmp gets deprecated?
>>
>> We use /proc/self/loginuid already, and try to resolve that UID using
>> NSS.  We still have fallback to __getutline_r.  I think it would be
>> really helpful if you could discover why that fallback is used.  I would
>> have thought it's dead code.
>>
>> Is it because /proc/self/loginuid is missing, or because NSS fails for
>> some reason?  If it's about /proc/self/loginuid, maybe we can look at
>> the owner of /dev/tty instead.
> 
> I made an half-automatic analysis of the binaries and corresponding
> source code and it seems I looked at the wrong sysdeps file in the glibc
> sources :( I didn't checked at runtime as I never know if I hit the
> correct execution path or not.

Indeed, we keep a lot of half-baked implementations not really used anywhere
as fallback for some theoretical 'unix' system.  I think we should just 
remove them altogether.

> Sorry, with the current glibc implementation we should be fine, so I
> will create bug reports against the projects who implemented their own
> getlogin() function based on utmp.
> 
> Thanks, I will fix my document.
> 
>   Thorsten
> 

Re: 64-bit time_t and __WORDSIZE_TIME64_COMPAT32

[Thorsten Kukuk]

On Tue, Feb 14, Florian Weimer wrote:

> * Thorsten Kukuk via Libc-alpha:
> 
> > I think we don't lose anything if btmp and lastlog don't exist anymore.
> > Querying utmp for the runlevel in systemd times is also obsolete.
> > Statistical data how many users are logged in if you login or if you
> > call uptime is also only nice to have, nothing more.
> 
> This is something that systemd could do, in a far more reliable fashion
> (or the kernel audit subsystem, I assume).

It looks like systemd-logind provides already everything we need at least 
for w and who and many more cases.
We just need a simple interface or wrapper.

Updated https://github.com/thkukuk/utmpx/blob/main/Y2038.md#ideas-for-solutions

  Thorsten

-- 
Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies
SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany
Managing Director: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman
(HRB 36809, AG Nürnberg)

Re: 64-bit time_t and __WORDSIZE_TIME64_COMPAT32

[Thorsten Kukuk]

Hi,

to give a short update on this:

lastlog: see https://www.thkukuk.de/blog/Y2038_glibc_lastlog_64bit/

openSUSE Tumbleweed and MicroOS use already lastlog2, we are starting now
to remove the "old" lastlog code and usage. ALP is currently switching
to it.


wtmp: see https://www.thkukuk.de/blog/Y2038_glibc_wtmp_64bit/

Even if many applications write wtmp entries in a chaotic or wrong way,
there is only one application from relevance reading it: last.
lslogins reads it, too, don't know how often it is really used. adjtimex
reads it, too, but I haven't found any application writing this type of
entries adjtimex tries to read.

wtmpdb is currently in security review, afterwards we will switch to it,
too. Everything is already prepared for this.


utmp: see https://www.thkukuk.de/blog/Y2038_glibc_utmp_64bit/

systemd accepted the necessary patches, v254 should contain them. First
upstream projects accepted the necessary adjustements, too. 
Main usage of utmp is to find out how many users are logged in, else
there are wall, write, who and w.
For coreutils patches exist beside who, procps accepted already the
first bunch, util-linux has open PRs for the next release, Linux-PAM
accpeted them, too. Will be in the next release the coming days.

Only problem is openssh, since they know the TTY only after PAM
authentication and systemd-logind has no interface to adjust the TTY
later. I will look into this next.

So from my point of view, dropping lastlog and wtmp should be straight
forward, utmp will need quite some more work.

  Thorsten

-- 
Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies
SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany
Managing Director: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman
(HRB 36809, AG Nürnberg)

Re: 64-bit time_t and __WORDSIZE_TIME64_COMPAT32

[Adhemerval Zanella Netto]

On 11/04/23 08:40, Thorsten Kukuk via Libc-alpha wrote:
> 
> Hi,
> 
> to give a short update on this:
> 
> lastlog: see https://www.thkukuk.de/blog/Y2038_glibc_lastlog_64bit/
> 
> openSUSE Tumbleweed and MicroOS use already lastlog2, we are starting now
> to remove the "old" lastlog code and usage. ALP is currently switching
> to it.
> 
> 
> wtmp: see https://www.thkukuk.de/blog/Y2038_glibc_wtmp_64bit/
> 
> Even if many applications write wtmp entries in a chaotic or wrong way,
> there is only one application from relevance reading it: last.
> lslogins reads it, too, don't know how often it is really used. adjtimex
> reads it, too, but I haven't found any application writing this type of
> entries adjtimex tries to read.
> 
> wtmpdb is currently in security review, afterwards we will switch to it,
> too. Everything is already prepared for this.
> 
> 
> utmp: see https://www.thkukuk.de/blog/Y2038_glibc_utmp_64bit/
> 
> systemd accepted the necessary patches, v254 should contain them. First
> upstream projects accepted the necessary adjustements, too. 
> Main usage of utmp is to find out how many users are logged in, else
> there are wall, write, who and w.
> For coreutils patches exist beside who, procps accepted already the
> first bunch, util-linux has open PRs for the next release, Linux-PAM
> accpeted them, too. Will be in the next release the coming days.
> 
> Only problem is openssh, since they know the TTY only after PAM
> authentication and systemd-logind has no interface to adjust the TTY
> later. I will look into this next.
> 
> So from my point of view, dropping lastlog and wtmp should be straight
> forward, utmp will need quite some more work.

Thanks for the follow up, it seems these interface are either legacy or
they are not really meant to be on libc (as musl did). Moving out to use
systemd or an external isolated process along with some IPC is indeed
way better approach.

I wonder if it would be better as a long term to add a switch 
--disable-utmp (similar to --disable-crypt) which just set these functions
to return ENOSYS without any compatibility support.  It is highly unlike 
that we will ever get a proper fix for BZ#24492 [1] or add support for 
64-bit time_t for these interface, which are both either security or 
usability issues.

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=24492

Re: 64-bit time_t and __WORDSIZE_TIME64_COMPAT32

[Thorsten Kukuk]

Hi,

a short update on this:

openSUSE Tumbleweed and MicroOS are using logind instead of utmp for
most applications since 1,5 week. An issue with uptime on Raspberry Pi's
is left (https://bugzilla.suse.com/show_bug.cgi?id=1215548), else there
are no open bug reports and it looks like majority of users did not even
noticed the switch :)
We still have the old files for compat reasons with the few not yet
adjusted packages, but I plan to remove them if we include systemd v255
and glibc allows to disable the interface.

Majority of patches are already upstream accepted, most of them even 
released.

I changed systemd so that systemd v255 will not use utmp but logind
internal, too.

I made presentations at All Systems Go! and OSS Europe and there I
received only positive feedback.
Especially "embedded" distributors were very interested in this (beside
the few people who think that 2038 is far, far away and we should not
care about this for the next decade).

On Tue, Apr 11, Adhemerval Zanella Netto via Libc-alpha wrote:

> I wonder if it would be better as a long term to add a switch 
> --disable-utmp (similar to --disable-crypt) which just set these functions
> to return ENOSYS without any compatibility support.  It is highly unlike 
> that we will ever get a proper fix for BZ#24492 [1] or add support for 
> 64-bit time_t for these interface, which are both either security or 
> usability issues.
> 
> [1] https://sourceware.org/bugzilla/show_bug.cgi?id=24492

With the current state and feedback I think this is the best solution
for glibc going forward.
And for people who don't want to use systemd, there is still utmps and
similar projects, so utmp implementation outside of glibc.

  Thorsten

-- 
Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies
SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany
Managing Director: Ivo Totev, Andrew McDonald, Werner Knoblich
(HRB 36809, AG Nürnberg)

Re: 64-bit time_t and __WORDSIZE_TIME64_COMPAT32

[Paul Eggert]

On 4/11/23 04:40, Thorsten Kukuk via Libc-alpha wrote:

> wtmp: see https://www.thkukuk.de/blog/Y2038_glibc_wtmp_64bit/
> 
> Even if many applications write wtmp entries in a chaotic or wrong way,
> there is only one application from relevance reading it: last.

Also, coreutils "who", "users", "pinky", and "uptime", e.g., the shell 
command:

who /var/log/wtmp

which is used on occasion (e.g., <https://linuxhandbook.com/who-command/>).


> For coreutils patches exist beside who

<https://www.thkukuk.de/blog/Y2038_glibc_utmp_64bit/> points to 
<https://github.com/thkukuk/utmpx/tree/main/coreutils> which 404s. So I 
assume you're talking about 
<https://github.com/thkukuk/utmpx/tree/main/patches/coreutils>? These 
are proof-of-concept (e.g., "who" needs patching).

Also, will the decision about whether the old or new format is used be 
something that the coreutils builder knows at compile time? or will it 
be something switchable by the ops staff at runtime, so (e.g.) "who" 
should be prepared to read either format?

Re: 64-bit time_t and __WORDSIZE_TIME64_COMPAT32

[Thorsten Kukuk]

On Tue, Apr 11, Paul Eggert wrote:

> On 4/11/23 04:40, Thorsten Kukuk via Libc-alpha wrote:
> 
> > wtmp: see https://www.thkukuk.de/blog/Y2038_glibc_wtmp_64bit/
> > 
> > Even if many applications write wtmp entries in a chaotic or wrong way,
> > there is only one application from relevance reading it: last.
> 
> Also, coreutils "who", "users", "pinky", and "uptime", e.g., the shell
> command:

At least "pinky" does not read wtmp but utmp.
For the rest: there are better ways to find out how many users are
logged in (utmp) or how many entries wtmp has...
I don't understand for what this should be good? It's absolute
meaningless how many old records wtmp contains, it depends on when
logrotate did the last cleanup...

> who /var/log/wtmp

That's the equivalent of "last". Since there will be no wtmp anymore, you
have to use "last" (gives you the same informations) or we have to
implement wtmpdb support into who. Don't know if this makes really
sense.

> which is used on occasion (e.g., <https://linuxhandbook.com/who-command/>).
> 
> 
> > For coreutils patches exist beside who
> 
> <https://www.thkukuk.de/blog/Y2038_glibc_utmp_64bit/> points to
> <https://github.com/thkukuk/utmpx/tree/main/coreutils> which 404s. So I
> assume you're talking about
> <https://github.com/thkukuk/utmpx/tree/main/patches/coreutils>? These are
> proof-of-concept (e.g., "who" needs patching).

Correct, things are moving faster than I'm able to update the blog...

The patches are WIP in the regard they are tested and working, but since I
don't understand how the coreutils configure framework works that is
missing. I have already a working "who", I just need some more time for
cleanup. I had to work on other tasks first.

And since there will be no "utmp" and "wtmp" files anymore, there is no
need to support reading them. 

> Also, will the decision about whether the old or new format is used be
> something that the coreutils builder knows at compile time? or will it be
> something switchable by the ops staff at runtime, so (e.g.) "who" should be
> prepared to read either format?

As you can see from the patches it's currently either systemd or
utmp/wtmp, not both. libsystemd does not always return an error if
systemd-logind is not used (or I haven't found out yet how to test for
that, needs more time), so this is hard to decide at runtime.

But to be honest: I doubt that people will compile their userland
applications with systemd support and use it on systems without systemd:
libsystemd does not seem to be designed for that use case, so will create
more problems than anything else, should be already the case with other
already existing tools, too.

  Thorsten

-- 
Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies
SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany
Managing Director: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman
(HRB 36809, AG Nürnberg)

Re: 64-bit time_t and __WORDSIZE_TIME64_COMPAT32

[Paul Eggert]

On 4/11/23 23:55, Thorsten Kukuk via Libc-alpha wrote:

> At least "pinky" does not read wtmp but utmp.

Oh, you're right, so it's just "who", "users" and "uptime". And "users" 
isn't that useful for reading wtmp, and a lot of people use procps-ng 
"uptime" rather than coreutils "uptime", so "who" is the biggest problem 
here.

> there are better ways to find out

I'm sure there are, but the problem is that users might be relying on 
these older ways of finding out.

> I don't understand for what this should be good?

People wrote shell scripts before "last" became common, or didn't know 
about "last", or wanted to be portable to old systems that lack "last", 
or whatever.

> That's the equivalent of "last". Since there will be no wtmp anymore, you
> have to use "last" (gives you the same informations) or we have to
> implement wtmpdb support into who. Don't know if this makes really
> sense.

If you want to decommission this coreutils functionality, I suggest 
taking it up with the coreutils maintainers - that's a better spot than 
this mailing list.