Antw: [EXT] Re: Failing UnitTest for Journald

["Ulrich Windl" <Ulrich.Windl@xxxxxxxxxxxxxxxxxxxx>]

>>> Lennart Poettering <lennart@xxxxxxxxxxxxxx> schrieb am 06.07.2021 um 11:15
in
Nachricht <YOQfRHFU4pNzn3qJ@gardel-login>:
> On Mo, 05.07.21 18:46, Andreas Krueger (Andreas.Krueger@fmc‑ag.com) 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.

I don't know how such a client would be named then, but have you considered
naming it "stale-PID-<PID>"?
At least then the users could notice that something might not work as
expected.

While trying to lear I found that in my manual page for
SYSTEMD-JOURNALD.SERVICE a page sd_journal_print(4) is referred to, but it
dpoes not exist in my system (systemd-228-157.27.1.x86_64 of SLES12)...

> 
> 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).

Regards,
Ulrich

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



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