![](https://seccdn.libravatar.org/avatar/bce881f00c17a1bf997473f19b54e1d4.jpg?s=120&d=mm&r=g)
Hi, I wrote already about Y2038 and the problems with utmp and wtmp. Since we have already solutions active for some weeks, we will now do the next steps: We replaced /var/log/wtmp with wtmpdb some months ago. /usr/bin/last does not use /var/log/wtmp anymore since quite some time, too. So the next logical step will be, that we don't create /var/log/wtmp anymore. Existing files will not be deleted and many tools will still write into it, but new installations will not create it anymore. After this, we have to find the applications, which don't use the glibc interface and try to manage this file at their own. They could still create that file. The majority of known applications are using logind meanwhile instead of /run/utmp. The bug reports are all fixed meanwhile, so we will go the next step: disabling /run/utmp. A systemd with disabled utmp support will be submitted most likely next week, and then we will see how long it takes to get it through the stagings. There are still some open SRs which the package maintainers ignores since several weeks. This should not affect anybody, but if yes, please complain to the responsible package maintainers. If you know about an important application still reading (not writing) /run/utmp, please speak up now. Thanks, 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)