2038年的问题可能导致该年部分软件失效。 该问题会影响使用基于 POSIX 的时间表示的程序。
托尔斯滕·库库克， 队长 来自 SUSE 未来科技 （Future Technology Team，开发 openSUSE MicroOS 和 SLE Micr），曾领导 SUSE LINUX Enterprise Server 项目 10 年， 建议删除 /var/run/utmp 文件 在发行版中 以完全解决 Glibc 中的 Y2038 问题。
有了它 建议移动所有使用 utmp、wtmp 和 lastlog 的应用程序 使用 systemd-logind 获取用户列表。
19 年 2038 月 XNUMX 日，计时器将溢出 指定期间 通过 32 位 time_t 类型。 在 Glibc 中，尽管引入了 64 位 time_t 类型，但为了保持与 32 位用户空间应用程序的兼容性，在 32 位平台上某些情况下仍然使用 64 位 time_t 类型。
在例如 x86-64 上使用 glibc 的 utmp/utmpx 有两个主要问题：
时间用了一个32位的time_t域，到2038就会溢出
存在允许 DoS 攻击的设计问题（utmp/wtmp 阻止允许非特权用户拒绝服务）
glibc 开发人员对第二个问题的分析表明，需要一个额外的守护进程来处理 utmp/utmpx 访问。虽然还有一些问题...
一个这样的例子是文件 /var/run/utmp，它存储有关当前连接到系统的用户的数据。 utmp 中的时间字段使用 32 位 time_t 值设置。
据说， 随着时间的推移，简单地将 utmp 中的字段从 32 位类型更改为 64 位类型是行不通的， 因为这会改变 Glibc ABI（类型会在 login()、getutid() 和 utmpname() 等函数中改变）并破坏与使用 utmp 的应用程序的兼容性，包括 w、who、uptime、login、su、sudo、useradd 、systemd、sysvinit、tcsh、xterm 显示管理器、emacs、openssh、qemu、samba、rsyslog 等。
由于潜在的陷阱和勤奋， 的开发商 glibc拒绝了替换utmp中time_t类型的位长的想法。 出于同样的原因，使用 utmp 结构中的可用空间来添加额外的 64 位时间字段的选项已被删除。
另外，更改utmp中类型的位深度并不能解决其他存在的问题，例如写入utmp需要特殊权限，这需要进程被授予额外的权限。 另一个问题是 utmp 架构允许本地用户通过操纵文件锁来执行破坏 utmp 服务的 DoS 攻击，从而无法确定 utmp 的内容是否反映了系统的实际状态。
建议使用额外的后台进程来处理对 utmp 的访问， 但是对于这样的任务，已经有一个 systemd-logind 进程，不建议启动另一个专门的进程（应用程序必须同时将数据传输到两个控制器）。
同时，即使解决了 DoS 攻击问题，utmp 的内容仍然只是提供信息，不能保证反映现实。
例如，不同的终端仿真器和多路复用器以不同方式反映它们的状态：运行五个 GNOME 终端将导致在 utmp 中镜像一个用户，而在 KDE 中运行五个 konsole 或 xterm 终端将导致六个。 类似地，screen 和 tmux 的行为不同，在第一种情况下，每个会话都被计为一个单独的用户，而在第二种情况下，所有会话只反映一个用户。
结果，作为最简单的解决方案， 建议移植所有应用程序以使用 systemd-logind 服务 替代方案已经存在，并且在没有真正的程序访问 utmp 之后，停止写入 utmp。 为了取代 wtmp，建议准备 API 以编写和读取有关使用 systemd-journald 的用户的信息。
最后值得一提的是下个版本的代码库 systemd 254 已经包含必要的功能 通过 DBUS 使用 sd-login.ho API 通过 libsystemd 提供替换 utmp 数据。
如果您有兴趣了解更多，可以查阅详情 在下面的链接中。