Y2038: utmp, wtmp and lastlog
How openSUSE solved this
Thorsten Kukuk
I'm a Distinguished Engineer at SUSE and with the company now for more than 25 years. Additional I'm Senior Architect and leading the Future Technology Team. Previously, I was the primary Project Manager for the SLES for over a decade. I have a long history in open source projects.
No video of the event yet, sorry!
The year 2038 problem (also known as Y2038) is a time formatting bug on Unix systems with representing times after 03:14:07 UTC on 19 January 2038. This happens with a 32bit time_t, not with a 64bit time_t. The general statement so far has always been that on 64bit systems with a 64bit time_t you are safe with respect to the Y2038 problem. But this isn't correct: on bi-arch systems like x86-64 (so which can execute 64bit and 32bit binaries) glibc defines __WORDSIZE_TIME64_COMPAT32, which leads to the fact, that struct utmp (used for utmp, wtmp and btmp) and struct lastlog uses int32_t instead of time_t. So we have a Y2038 problem, which is not easy fixable, as this would require ABI and on disk format changes. In this talk I will speak about the background, which tools are affected and how we solved that in openSUSE by dropping utmp, wtmp, btmp and lastlog completely and make use of systemd-logind and other tools instead.
- Date:
- 2024 June 27 - 15:30
- Duration:
- 30 min
- Room:
- Gallerie
- Conference:
- openSUSE Conference 2024
- Language:
- Track:
- New Technologies
- Difficulty:
- Easy
- Regulatory Compliance and Foundation Support in Open Source: Pathways to Competitive Advantage
- Start Time:
- 2024 June 27 14:45
- Room:
- Seminar Room 2
- Leap 16.0 branding focus group
- Start Time:
- 2024 June 27 15:30
- Room:
- Seminar Room 1
- Working together in one place with Nextcloud
- Start Time:
- 2024 June 27 15:30
- Room:
- Saal