Hi Valentin, thanks for digging into this, and sharing what you find out!
All my tests have been on older distro versions, not Debian 13, so that might show similar test failures to newest Ubuntu, I don't know. Ubuntu is forked off Debian unstable (I think), perhaps this also shows the syslogd.sh test failures, I don't know. Inetutils 2.6 includes a commit that fixes building '--with-systemd': <https://cgit.git.savannah.gnu.org/cgit/inetutils.git/commit/?id=a172b7689899a304ebb1c5061d3520a2414f8c6f>. Building Inetutils with "./configure --enable-systemd" did not change the test results for me. I would expect syslogd to skip utmp entries without a (pseudo) TTY. I don't (yet) understand if that should be done in src/syslogd.c, or in Gnulib, or if such code is already there, but not yet adjusted to current utmp contents. The utmp(5) man page <https://man7.org/linux/man-pages/man5/utmp.5.html> describes utmp.ut_line as 'Device name of tty - "/dev/"'. POSIX describes utmpx.ut_line as 'Device name' <https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/utmpx.h.html>. Syslogd uses whatever was returned in .ut_line as a (pseudo) TTY name. Perhaps it should verify this first, if only for robustness? But how could it verify that .ut_line really contains a (pseudo) TTY name? I'll also keep looking into this. Cheers, Erik On Wed, Nov 12, 2025 at 02:19:33PM +0100, Valentin Haudiquet wrote: > Ok, I should have read the definition of "utmp" before writing > previous email. Of course then, utmp "keep track of all logins and > logouts to the system" it seems, and it effectively is the root cause > of the issue. > > Still, I'm not familiar with that protocol / files. > I wonder: > - Are we doing something different on Ubuntu that fails that test, and > then we should disable UTMP alltogether on Ubuntu ? > - Is there a bug in libsystemd / inetutils / the syslogd test that > fails with what is specifically done on Ubuntu ? > > I'm sure other distributions are using tty entries for login screens > or sshd, even debian, so I fail to understand why Ubuntu is different > now. > > I will keep investigating, I'm trying to share as much as possible > when I finally understand something :) > > Thanks! > > On Wed, 12 Nov 2025 at 14:13, Valentin Haudiquet > <[email protected]> wrote: > > > > After some testing: > > - The newer package also fails the tests on Questing > > - The older package passes the tests on Questing and Resolute > > > > So there must be something part of that package. I studied the diff, > > and some parts got my attention: > > - debian/changelog 2.6-2, (I don't know how I missed that before...) > > > + * Enable libsystemd support to restore utmp functionality in > > > + syslogd and talkd, on systems running systemd. > > - debian/rules > > > + confflags += --enable-systemd > > > > So that "libsystemd" enablement to restore "utmp" fonctionality might > > be the root cause. I'm not completely sure what all of this changes, I > > will try to keep investigating. I guess libsystemd might have > > something to do with the tty sessions we mentioned earlier. > > > > On Wed, 12 Nov 2025 at 13:05, Valentin Haudiquet > > <[email protected]> wrote: > > > > > > Hi, > > > > > > > Since the testing user is only notified when VERBOSE=yes, this should > > > > not > > > happen with just "make TESTS=syslogd.sh check", i.e., that should pass. > > > > > > Indeed, it's a PASS on my machine. > > > > > > > Do you see any suspicious lines in the output of the "w", "who", and/or > > > "last" commands? I.e., any entry in the TTY column that does not look > > > like a TTY, or a missing entry in that column? > > > > > > Yes ! w and who are normal, but last shows: > > > ``` > > > [vhaudiquet@x1c inetutils <merge-lp2130124-resolute>]$ last > > > vhaudiqu tty2 tty2 Thu Nov 6 12:00 - still logged in > > > vhaudiqu seat0 login screen Thu Nov 6 12:00 - still logged in > > > vhaudiqu tty2 tty2 Sat Nov 1 19:03 - still logged in > > > vhaudiqu seat0 login screen Sat Nov 1 19:03 - still logged in > > > vhaudiqu tty2 tty2 Tue Oct 28 11:39 - still logged in > > > vhaudiqu seat0 login screen Tue Oct 28 11:39 - still logged in > > > vhaudiqu tty2 tty2 Tue Oct 28 07:02 - still logged in > > > vhaudiqu seat0 login screen Tue Oct 28 07:02 - still logged in > > > vhaudiqu tty2 tty2 Mon Oct 27 17:36 - still logged in > > > vhaudiqu seat0 login screen Mon Oct 27 17:36 - still logged in > > > vhaudiqu tty2 tty2 Mon Oct 27 16:44 - still logged in > > > vhaudiqu seat0 login screen Mon Oct 27 16:44 - still logged in > > > vhaudiqu tty2 tty2 Tue Oct 7 17:11 - still logged in > > > vhaudiqu seat0 login screen Tue Oct 7 17:11 - still logged in > > > vhaudiqu tty2 tty2 Thu Oct 2 23:13 - still logged in > > > vhaudiqu seat0 login screen Thu Oct 2 23:13 - still logged in > > > vhaudiqu tty2 tty2 Thu Oct 2 14:29 - still logged in > > > vhaudiqu seat0 login screen Thu Oct 2 14:29 - still logged in > > > vhaudiqu tty2 tty2 Thu Oct 2 14:26 - still logged in > > > vhaudiqu seat0 login screen Thu Oct 2 14:26 - still logged in > > > vhaudiqu tty2 tty2 Thu Oct 2 12:34 - still logged in > > > vhaudiqu seat0 login screen Thu Oct 2 12:34 - still logged in > > > vhaudiqu tty2 tty2 Thu Oct 2 12:00 - still logged in > > > vhaudiqu seat0 login screen Thu Oct 2 12:00 - still logged in > > > vhaudiqu tty2 tty2 Thu Oct 2 11:50 - 11:59 (00:09) > > > vhaudiqu seat0 login screen Thu Oct 2 11:50 - still logged in > > > vhaudiqu tty2 tty2 Thu Oct 2 11:35 - still logged in > > > vhaudiqu seat0 login screen Thu Oct 2 11:35 - still logged in > > > vhaudiqu tty2 tty2 Thu Oct 2 11:20 - still logged in > > > vhaudiqu seat0 login screen Thu Oct 2 11:20 - still logged in > > > ``` > > > > > > However, that is also the case on Questing and older Ubuntu releases. > > > And to my understanding that is normal :) > > > On the autopkgtest, the VERBOSE variable is set, and my guess is that > > > the machine running those being a server and not a desktop, there is > > > no "seat0" but "sshd" sessions arround, which explains that error. > > > > > > Something must have changed, that before did not pick up those > > > sessions and now picks them up instead of the right one ? > > > I'm not sure indeed which part of the system handles that, but I will > > > try to reproduce on different versions of Ubuntu with different > > > versions of the package and keep you posted. > > > > > > Thanks ! > > > Valentin > > > > > > On Wed, 12 Nov 2025 at 11:37, Erik Auerswald <[email protected]> > > > wrote: > > > > > > > > Hello Valentin. > > > > > > > > On Wed, Nov 12, 2025 at 09:37:42AM +0100, Valentin Haudiquet wrote: > > > > > > > > > > Thank you for looking at the bug, I'm sorry I wasn't available to give > > > > > you an answer earlier. > > > > > > > > No problem, thanks for the follow up. > > > > > > > > > I just applied your patch and ran the test locally on my machine with > > > > > `make TESTS=syslogd.sh VERBOSE=yes check >log.txt 2>&1`, and it still > > > > > fails in the same way. I'm on Ubuntu 26.04 development preview > > > > > (resolute raccoon). The log.txt file is attached, along with > > > > > tests/syslogd.sh.log. > > > > > > > > > > The difference here is that it complains about a missing "/dev/seat0" > > > > > instead of "/dev/sshd". > > > > > > > > Thanks! The logs show that the generated syslogd configuration files > > > > look as expected. > > > > > > > > I think the following happens: > > > > > > > > 1. VERBOSE=yes results in adding a line to message the user running > > > > the tests to the first generated configuration file. > > > > > > > > 2. When syslogd reads information about logged in users in order to > > > > determine which (pseudo) TTYs need to be messaged, it finds > > > > something > > > > different ("/dev/sshd" or "/dev/seat0") that does not represent a > > > > (pseudo) TTY. > > > > > > > > 3. When attempting to send a message to such a non-(pseudo) TTY, this > > > > fails, and syslogd logs an error message. > > > > > > > > 4. The tests don't expect syslog error messages and thus fail. > > > > > > > > Since the testing user is only notified when VERBOSE=yes, this should > > > > not > > > > happen with just "make TESTS=syslogd.sh check", i.e., that should pass. > > > > > > > > Do you see any suspicious lines in the output of the "w", "who", and/or > > > > "last" commands? I.e., any entry in the TTY column that does not look > > > > like a TTY, or a missing entry in that column? > > > > > > > > > I will try to investigate a bit more as well; it seems that those > > > > > tests are passing on resolute for inetutils 2.6-1ubuntu3, so I will > > > > > try to look for the diff with 2.6-4ubuntu1 around that test, even > > > > > though I did not find anything relevant at first. > > > > > > > > It might be related with utmp reading functions in Glibc or possibly > > > > Gnulib replacements for those. I am not familiar with this, and > > > > the syslogd source seems to implement different methods to read this > > > > information depending on what functions are available. I do not expect > > > > to find a quick solution. I do think that there is a bug (or missing > > > > interoperation feature) somewhere, but I am not even sure where. > > > > > > > > Cheers, > > > > Erik
