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
