Hi Valentin, On Fri, Nov 14, 2025 at 11:15:45AM +0100, Valentin Haudiquet wrote: > On Fri, 14 Nov 2025 at 09:15, Erik Auerswald <[email protected]> > wrote: > > > Could you test this functionality for both the older and newer packages? > > Open at least one terminal window that can receive log messages > > (i.e., that is registered in utmp, possibly by starting "screen" > > inside the terminal), and then run the syslogd tests in verbose mode > > (make TESTS=syslogd.sh VERBOSE=yes check). Are log messages sent to > > that terminal window? > > With the newer package: I don't see anything, either in XTerm, screen, > ... nothing... except when logging in directly in /dev/tty3 ! There I > see messages (syslogd: /dev/seat0 errors, but notification messages > nevertheless).
OK, as I feared, the "utmp compatibility" is rather limited, i.e., most software has not yet been changed to use the new method. > With the older package: no message at all. OK, this should be reflected in another test error: tests/utmp.sh should fail. Is that the case? > So this confirms that the utmp functionality was just not seeing > anything before, and is now able to see something else, either the > linux virtual terminals or the seat0/sshd/graphical sessions. > > I'm not sure what to do now. After some internal discussions, it seems > that everyone wants to just remove the utmp features of inetutils on > Ubuntu, and go back to what was before (i.e. utmp functionality not > seeing any session). > > I would like to keep the package as close as possible to Debian, and > find a fix for that, but I'm not even sure what to fix. Should > inetutils/syslogd be more careful about which sessions it uses? Should > utmp/wtmp/something not expose those seat0/sshd sessions? Is that > something to fix in systemd? I'm not sure. > > If you have any insights, feel free to share :) As I understand it, syslogd, talkd, telnetd, XTerm, and screen, to give a few examples, are based on the idea that only active user sessions with a TTY are found as USER_PROCESS entries in utmp. If they are missing from utmp, syslogd and talkd cannot send messages to users. If other entries without usable TTY are found as type USER_PROCESS, sending messages to those fails, resulting in error messages. As a result, the compatibility enabled with "configure --enable-systemd" does not yet work well (e.g., it results in syslogd errors). IMHO both breaking user messaging functionality by not enabling the new compatibility feature, and creating many error messages with only a few special cases (i.e., Linux Virtual Terminal) actually working, are bad. I'd say you can choose either of those for Ubuntu, both should result in one test or the other failing (syslogd.sh or utmp.sh). I'd say I'd slightly prefer to not enable the problematic compatibility layer, because I'd think this is cleaner. Having syslogd.sh pass and utmp.sh fail without "--enable-systemd" would better reflect reality than the other way around with "--enable-systemd". > I will try to look into the relationship between systemd / utmp, and > if there is a standard for what should be exposed there. The GNU Inetutils have a BSD history, with POSIX as a (later!) relevant standard. I know of current GNU Inetutils use on non-GNU/Linux systems, and I do not want to break this. An extended compatibility layer in Gnulib that filters out useless utmp entries might be a way forward. Such filtering could require setting a new option, such that the syslogd and talkd code would need to add another constant to the read_utmp() invocation (perhaps something like READ_UTMP_CHECK_TTY). But I do not even understand how to use Gnulib, much less how to change anything there. I have no idea if anyone has any motivation to work on something like that, or if it would even be accepted into Gnulib. Technically, we could disable syslogd error messages when the TTY signalled via utmp does not exist, but that would also hide actual configuration errors that are currently diagnosed correctly. I do not like that. I think this compatibility problem would be bad enough that syslogd should not silently accept wrong TTY entries in utmp, i.e., the current behavior to attempt to send to any relevant TTY and report any errors should be kept. What do other people helping with GNU Inetutils maintenance think? Collin, Simon, anyone? Cheers, Erik
