Re: Failing UnitTest for Journald

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

On Mo, 05.07.21 18:46, Andreas Krueger (Andreas.Krueger@xxxxxxxxxx) wrote:

> Hi Folks,
>
> for a customer I have to verify the behavior of the logger in its
> system (Linux debianVM 4.19.0-6-amd64 #1 SMP Debian
> 4.19.67-2+deb10u1 (2019-09-20) x86_64 GNU/Linux), which is journald
> (systemd 241 (241)).  For this, I have written some unit tests that
> work all well, when executed separately. But running together they
> lead to some erroneous behavior that I cannot explain - maybe you
> have an idea what's going wrong...

I am not sure I follow entirely what you are doing. But please be
aware of the following race we cannot fix without kernel changes:

Whenever journald receieves a log message from a client it uses the
SCM_CREDENTIALS metadata of the incoming packet to retrieve further
medadata from /proc/$PID/ about the client. If the sender's process
exited by the time the message is processed this data is not available
anymore, and thus will not be stored along with the message, and can
thus not be used to search/filter for the message.

Thus: whenever you have a process that logs and immediately exits
there's a chance that once journald processes that log message, it is
seen and written to disk but without much of the metadata. If you then
use "journalctl -u" or a similar command (e.g. the log output of
systemctl status) to look for the logs of the unit it will likely not
be found since the unit name is one of the metadata fields not
available in this case (since it is extracted from the
/proc/$PID/cgroup file by journald).

You should see the log message if you do not use filtering though,
i.e. "journalctl -e" or so should show it.

We'd really like to fix this one day, but unfortunately kernel
developers so far shot down any attempt to optionally attach more
metadata to AF_UNIX datagrams (if we had just the cgroup this would
already make things *so* much better for us).

Lennart

--
Lennart Poettering, Berlin
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel