Also, a colleague of mine sent me that gnulib commit: https://github.com/coreutils/gnulib/commit/757345e8bad8cec0e05f9e1a0668232048a6c44c
That one seems to be missing on inetutils version of gnulib, and as far as I understand it might provide what we were missing, e.g. the difference between the login sessions and the real user sessions. That might be the start of a cleaner implementation, but IMHO checking for ENOENT seems fine for now. Thanks again! Valentin On Mon, 1 Dec 2025 at 09:25, Valentin Haudiquet <[email protected]> wrote: > > Hi! > > Thank you for this patch! It works indeed when testing locally, I see > the messages on tty3 but no errors, and the test passes. I will go > ahead and push that patch to Ubuntu, and send it to Debian. > > We are almost sure now that this bug indeed happens on Debian as well, > but they missed it because their autopkgtests are ran in containers > and not VMs, and thus don't have full sessions and utmp entries (in an > Ubuntu LXC container, the test is a PASS as well). > > I'm really happy that the solution was that simple in the end :) > > I don't want to be too happy too soon, so I will build that package > with the patch and start the automated testing. > > Are you willing to implement that patch upstream? With the ifdef, it > should not bother any other system indeed, so it should be fine, > right? > > Thanks! > Valentin > > On Sat, 29 Nov 2025 at 20:53, Erik Auerswald <[email protected]> > wrote: > > > > Hi Valentin, > > > > On Tue, Nov 18, 2025 at 03:06:28PM +0100, Erik Auerswald wrote: > > > On Tue, Nov 18, 2025 at 02:09:40PM +0100, Valentin Haudiquet wrote: > > > > [...] > > > > However, I recall from our previous conversations that you would > > > > not want to implement such a filter because of possible breaks on > > > > non-GNU systems, right? > > > > > > I do not want to break the currently working functionality for systems > > > with a /var/run/utmp file. I do not like the idea of suppressing a > > > legitimate error message on those systems just because a newer system > > > introduces them as a side effect of normal operation. As such I'd > > > prefer to filter entries without an existing TTY from the results > > > returned from this new system, but not from the existing one. > > > > > > Using "configure --enable-systemd" looks like an easy way for GNU > > > Inetutils to support user messaging on the newer systems. It would > > > be great if that just worked, but it doesn't. > > > > I may have found a small change to adjust user messaging to a system > > without "utmp" file when using "--enable-systemd". I think that > > "configure" prefers to use a "utmp" file if possible, and only falls > > back to non-utmp compatibility if there is none. > > > > On my Ubuntu 22.04 system, which still has a "utmp" file, > > "READUTMP_USE_SYSTEMD" is never defined: > > > > $ ./configure > > [...] > > $ grep SYSTEMD config.{status,h} > > config.status:S["SYSTEMD_CHOICE"]="no" > > config.h:/* #undef READUTMP_USE_SYSTEMD */ > > > > $ ./configure --enable-systemd > > [...] > > $ grep SYSTEMD config.{status,h} > > config.status:S["SYSTEMD_CHOICE"]="yes" > > config.h:/* #undef READUTMP_USE_SYSTEMD */ > > > > How does this look on the development version of Ubuntu 26.04? I would > > expect that "READUTMP_USE_SYSTEMD" is defined with "--enable-systemd" > > there, but not without. Could you test this and report back? > > > > If this idea is correct, then the attached patch should result in passing > > "syslogd.sh" and "utmp.sh" tests on the development version of Ubuntu > > 26.04 when "./configure --enable-systemd" is used. If this works for > > "syslogd", then this could also work for "talkd", but have neither tested > > nor looked into "talkd" yet. > > > > Could you try the attached patch and report back? The "syslogd" test > > should pass with and without "VERBOSE=1", and if the test user is logged > > into a Linux virtual console, e.g., tty3, then the test send messages > > there with "VERBOSE=1". There should not be any unexpected error messages > > regarding not existing files. > > > > Thanks, > > Erik
