search

thkukuk / utmpx

A libutmp PoC to solve the Y2038 (32bit time_t) problems with utmp/wtmp/lastlog on 64bit archs
9 stars 1 forks source link

Projects depending on utmp/wtmp/btmp/lastlog beyond openSUSE Tumbleweed server installation. #2

Open loqs opened 4 months ago

loqs commented 4 months ago

Would you be interested in adding such other projects? This is in relation to https://gitlab.archlinux.org/archlinux/packaging/packages/libutempter/-/issues/1. In that context additional projects using libutempter that you have not listed are:

thkukuk commented 4 months ago

Since openSUSE Tumbleweed, MicroOS and the upcoming ALP are using libsystemd and not utmp already, I think it's time to archive this project...

The list of packages are the openSUSE Tumbleweed core packages only (so used on default installations), not all packages using utmp/wtmp/lastlog. That's much more. Your packages are all also part of openSUSE, just not installed by default. From my experience: if you switch to systemd instead of utmp, you can completely ignore libutempter and disable it. In all cases known to me, it just adds fake entries to utmp for "wall" messages. systemd-logind does not allow such "fake" entries. For some Desktops, this is especially annoying, as you get every message twice on a shell (once from the fake entry, once from the display manager), so if you have several terminals open, you get flooded with messages. For other Desktops (e.g. GNOME default setup), you will never see this messages. In the case of GNOME because GNOME creates broken fake entries which only leads to errors if you use wall. So my advice: independent of if you use utmp or systemd-logind: disable usage of libutempter and remove it. It was great a long, long time ago, but more or less useless today.

thkukuk commented 4 months ago

What I forgot about the ArchLinux Issue (sorry, I have no account to comment there): openSUSE switched already last year from utmp to systemd-logind. But we did not disable/remove the old code everywhere yet, because it does not harm: if there is no utmp/wtmp file, most of the implementations will do nothing. If they create an utmp/wtmp file, nothing will read it. You only need to make sure that no service (especially systemd-tmpfiles) create utmp/wtmp files. Between, systemd itself is also fixed to work completely without utmp file without loss of functionality (I think v254 or v255 got it).