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
