Hi Luca, everybody, any comment from your side on below mail or a general pointer on "the future of Debian and utmp"?
Thanks Jens On 2024-11-06 21:18, Jens Schmidt wrote: > [I hope this is the right way to address this question - apologies > if not or if I have overlooked an existing discussion ...] > > systemd version 256.7-2 on Debian disabled UTMP support (from the > Debian changelog): > > ,---- > | [ Luca Boccassi ] > | * systemd-boot: depend on systemd for kernel-install (Closes: #1085012) > | * Disable utmp support, not y2038 safe. utmp support in tmux has been > | disabled, so autopkgtest should no longer break > | * Backport fixes for upstream autopkgtest suite > `---- > > As a result, no `utmp' file is created on systems having that version > of systemd installed. However, utmp(5) states that > > ,---- > | Unlike various other systems, where utmp logging can be disabled by re‐ > | moving the file, utmp must always exist on Linux. [...] > `---- > > And at least on my system I get the following errors logged in my > journal: > > ,---- > | [ 24.434215] host01 lightdm[2087]: Failed to write utmpx: No such file or > directory > | [...] > | [ 30.866566] host01 systemd[2094]: Started app-xterm1fxd.service - > /home/farblos/bin/lwsdi shutdown "FVWM Child" "Wait for explicit exit" block > xterm -name xterm1fxd -title "XTerm 1". > | [ 31.026661] host01 utempter[2538]: [ppid=2536] pututline: No such file > or directory > `---- > > Since: > > - I'd like to get rid of these warnings/errors, > - I'd like to have an `utmp' file that does *not* last across reboots > and > - I don't care (yet) about the Y2038 problem, > > I came up with file `/etc/tmpfiles.d/90-local-utmp.conf' containing > what `/usr/lib/tmpfiles.d/systemd.conf' previously provided, namely: > > ,---- > | f+! /run/utmp 0664 root utmp - > `---- > > Would that be the "correct" or "Debian-ish" way to provide an `utmp' > file that fulfills my above requirements? > > And: Should users file Debian bugs against applications still relying > on `utmp'? Or will there be some replacement for what systemd has > provided?
