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
