[systemd-devel] [PATCH] journald: check if socket is in connected state before forwarding to syslog

[Piotr Wilczek]

> -----Original Message-----
> From: Lennart Poettering [mailto:lennart at poettering.net]
> Sent: Friday, July 11, 2014 12:44 PM
> To: Piotr Wilczek
> Cc: systemd-devel at lists.freedesktop.org; Kyungmin Park; Lukasz
> Stelmach; Juho Son; Bartlomiej Zolnierkiewicz
> Subject: Re: [systemd-devel] [PATCH] journald: check if socket is in
> connected state before forwarding to syslog
> 
> On Fri, 11.07.14 09:52, Piotr Wilczek (p.wilczek at samsung.com) wrote:
> 
> > Currently syslog socket is not correctly verified if is in connected
> state.
> > This results in sending messages to a socket that is not connected
> > which is not allowed.
> >
> > In this patch the socket is correctly checked. If the socket is not
> > connected forwarding to syslog is disabled.
> >
> > This patch causes about 15% decrease in CPU usage on Trats2 when
> > ForwardToSyslog=yes but the syslog socket is not connected.
> 
> Not following here.
> 
> A) So, journald creates one listening AF_UNIX socket for syslog on
> /run/systemd/journal/dev-log (which /dev/log is then symlinked to).
> That's the socket you are checking. Which cannot really fail...
> 
> B) Now, as a shortcut we use the same sock actually, via sendto() to
> also pass data to /run/systemd/journal/syslog, which is where a
> secondary syslog server should listen on, which will then also receieve
> the data. THis one is likely to fail, because journald starts very
> early, and syslog daemons start very late, hence for the initial time
> no message can be delivered at all. Moreover, in many setups there is
> no secondary syslog, so this will fail each and every single time, but
> that's intended really.
> 
> Now, your patch apparently looks for errors wth step A), and you argue
> you want to get rid of CPU load of B), which I can't follow. Since A
> and B are actually kinda separate they just happen to use the same
> socket, because that was easier...
> 

The CPU load is higher becouse now messages are sent to a socket that is not
in a connected state. I wanted to avoid that with the present configuration.

> What I don't understand is why you need ForwardToSyslog= at all (which
> turns off B)? I mean, does Samsung actually really run a second syslog?
> If not, just set this to false.
> 
> In fact, we probably should turn this off by default now for everybody,
> since rsyslog and friends nowadays get their data directly from the
> journal, instead of using this socket...
> 

That would be the best for us.
Thank you for explanation.

> Anyway, not following what you are trying to do! Please elaborate!
> 
> Lennart
> 
> --
> Lennart Poettering, Red Hat