[systemd-devel] [systemd-commits] 4 commits - man/systemd.mount.xml man/systemd.swap.xml src/core src/fstab-generator src/journal src/shared

[Lennart Poettering]

On Wed, 26.11.14 12:22, Zbigniew Jędrzejewski-Szmek (zbyszek at kemper.freedesktop.org) wrote:

> New commits:
> commit 3d82301321afdcc4f2f8786883bd15b1a64c6e83
> Author: Zbigniew J??drzejewski-Szmek <zbyszek at in.waw.pl>
> Date:   Wed Nov 26 15:05:55 2014 -0500
> 
>     journald: proceed even if some sockets are unknown
>     
>     systemd-journald would refuse to start if it received an unknown
>     socket from systemd. This is annoying, because the failure more for
>     systemd-journald is unpleasant: systemd will keep restarting journald,
>     but most likely the same error will occur every time. It is better
>     to continue. journald will try to open missing sockets on its own,
>     so things should mostly work.
>     
>     One question is whether to close the sockets which cannot be parsed or
>     to keep them open. Either way we might lose some messages. This
>     failure is most likely for the audit socket (selinux issues), which
>     can be opened multiple times so this not a problem, so I decided to
>     keep them open because it makes it easier to debug the issue after the
>     system is fully started.

I think we really should close the fd here. audit is actually really a
good example why: the audit kernel side has a logic to pass audit msgs
to kmsg if no client is listening¹. If we keep the audit fd open, but
don't read from it this would mean the kmsg logic is turned off
without anyone ever seeing the audit msgs, which is something we
really should avoid I guess... 

Anyway, made the change now to close it. I hope that makes sense.

Lennart

Footnotes:

¹ Well, actually that logic is currently broken in the kernel, it only
  takes unicast audit clients into account. However, there's work
  going on to fix this in the kernel, and make sure the kmsg
  forwarding is turned off, too, when there's a mcast audit client
  running.

-- 
Lennart Poettering, Red Hat